Open to one role at a time

Founding Engineer and Fractional CTO for early-stage products

I'm Rares Serban, a senior engineer from Cluj-Napoca, Romania. I've been shipping production code for more than 10 years and leading small teams for 3 of them. Next to my own products I take one role at a time, as a founding engineer, fractional CTO or tech lead, for a product that is still early.
rares@beyondfolder: ~

$ whoami

rares serban, senior engineer, cluj-napoca (EET)

$ cat roles.txt

fractional CTO | tech lead | founding engineer

$ ls shipped/

mailyond omniyond nuxtbeyond distribution-framework docuyond

$ echo $STACK

rust typescript cloudflare aws ai

$

10+ years

Shipping code in production

3+ years

Leading small teams as tech lead

1,000+ events/s

On a Rust platform I architected

5 products

Built and launched by myself since 2025

What I can help with

I only take one of these at a time, so it gets proper attention. Which one makes sense depends on where the product is.
Fractional CTO
I'd rather say it up front, this one is a stretch. I've owned the architecture on 5+ projects and led small teams, but I never had the CTO title. It makes sense for a pre-seed product that needs someone to make the technical decisions and plan the first hires.
Tech lead
You have a few engineers and nobody really owns the architecture. I did this for 3+ years, first at Pitech+Plus from 2021 and then on projects at Buidly, making the technical decisions and helping developers grow through code reviews, pair programming and workshops.
Founding engineer
You have a validated idea or a first version and need someone to build the real product end to end. Backend, frontend, infrastructure and billing, including the boring parts.

What kind of product fits

Since it's one role at a time, I'm picky about which one I take.

A good fit

  • An early-stage product, pre-seed or seed, that already has real users or a paying pilot
  • TypeScript or Rust on the backend, and React, Vue or Nuxt on the frontend
  • Real-time data, event-driven systems, queues and long-running workflows
  • AI features that have to work in production (RAG, agents, MCP)
  • Cloudflare Workers or AWS, where someone has to own the infrastructure
  • Remote, with enough overlap with EU hours

Probably not a fit

  • Short gigs paid by the hour
  • Maintenance on a codebase nobody plans to change

Three products I built on my own

All three from the first commit to billing. For each one, what was hard, what I decided and where it is now.

Mailyond

One inbox for every domain you own

Launched June 2026

One inbox where you receive and reply as any of your domains, plus a Resend-compatible API for sending. I built it because I was answering support for 5 products from my personal Gmail.

Nuxt 4TypeScriptCloudflare WorkersD1R2PostmarkPolarMCP

What was hard

  • Every domain gets its own Postmark server, created through the Postmark account API, and the app generates and verifies the DKIM, Return-Path and inbound MX records. DNS is where most people give up, so this step has to explain itself.
  • Threading replies. Email doesn't have a thread id, you only get the Message-ID, In-Reply-To and References headers. So every message Mailyond sends gets a Message-ID built from its own database id, and when a reply comes back the thread is found from the headers instead of guessed from the subject.
  • Making the send API compatible with Resend, so the official Resend SDKs work if you only change the base URL. That meant matching things like arrays vs strings, snake_case fields and the error format, but it was much less work than writing and maintaining my own SDKs.

What I decided

  • Postmark handles the delivery. Running my own mail servers would have meant owning deliverability too.
  • A subdomain mode, so you can try it on support.yourdomain.com without moving your main inbox.
  • When you hit the plan limit, incoming mail still arrives and is stored. A support inbox that bounces customers is worse than paying an overage.

Where it stands

Live since June 2026, with a 7-day trial and an MCP server for AI agents. The honest number is 0 paying customers so far. People agreed the problem is real and still didn't switch, and that taught me more about validation than building it did.

Omniyond

Pay-per-use API toolbox for AI agents

Launched June 2026

A scheduler that runs any HTTP call once or on a repeat, plus page extraction, PDFs, OG images, QR codes and short links. You pay per call from prepaid credits, or the agent pays by itself with x402 in USDC on Base.

Nuxt 4TypeScriptCloudflare WorkersQueuesD1R2Browser Renderingx402MCP

What was hard

  • Scheduling on Workers without running a server of my own. A cron trigger runs every minute and pushes the due jobs to a Cloudflare Queue, then the consumer runs them and retries after 30 seconds, 5 minutes and 30 minutes, before they end up in a dead-letter queue.
  • Payments and retries. The payment settles before any paid work runs, so a payment that verifies but never settles doesn't get a free PDF. And a job that pays a downstream x402 API never retries once it settled, because a retry would pay twice.
  • Letting people schedule any URL means some of them will try to reach internal addresses. Node's DNS resolver doesn't really work on Workers, so hostnames are resolved over DNS-over-HTTPS and private ranges are blocked. If the resolver itself fails, the job is retried instead of being marked as blocked.

What I decided

  • Pay per call from one balance, with credits that never expire, because agents use tools in bursts.
  • I moved the pitch away from x402 and from "agents can't tell time" once agent runtimes shipped their own cron. The scheduler stayed, only the headline changed.

Where it stands

Live on Base mainnet through the Coinbase CDP facilitator, with card credit packs and an MCP server. No real traction yet, and I'm still figuring out the positioning.

Docuyond

AI support agent that answers from your docs

Launched October 2025, retired 2026

A chat widget you embed with one line. It answers your customers from your docs, files and web pages, and hands the chat to a person when it can't. It was my first AI product, and where I learned RAG, tool calling and the Vercel AI SDK.

Nuxt 4TypeScriptCloudflare WorkersD1R2AutoRAGWorkers AIAI GatewayVercel AI SDKBrowser RenderingStripe

What was hard

  • Keeping every customer's knowledge separate inside one Cloudflare AutoRAG index. Each widget's files, texts and web pages live in their own folder in R2, and every search is filtered to that folder, so one company's docs can never answer another company's customers.
  • Web pages as a source. The app opens the page with Cloudflare Browser Rendering, saves the HTML to R2 and asks AutoRAG to re-index. Indexing runs as a job with a cooldown, so the dashboard tracks the job and only lets you sync again when something changed.
  • The widget runs on other people's websites, so anyone can type into it. Messages are checked for prompt injection, answers are cleaned if they leak the system prompt, the iframe only loads on the domains you allow, and each chat has a message limit.

What I decided

  • The Vercel AI SDK with Cloudflare AI Gateway in front of every model, so switching models was a one-line change. I tried Llama 3.3 70B and Llama 4 Scout on Workers AI and Claude, and ended on GPT-5.1 chat because it was fast enough and cheaper than Claude. A small Llama model writes the chat titles.
  • The agent searches the knowledge base first and only offers a person after it tried. When someone answers an escalated question, an LLM turns the reply thread into a Q&A that goes back into the knowledge base, so next time the widget can answer it.

Where it stands

It got steady search traffic from its free tools, but only 1 paying customer, who later cancelled. I stopped working on it in June 2026 and retired it in September.

Before my own products

The jobs, which is where most of my tech lead experience comes from.

2026 to now

RWS (Papercup)

Senior Software Engineer, B2B contract

I'm the only full-stack engineer on the team of Papercup, the AI dubbing platform of RWS. I shipped audio-only support end to end as the only developer on it, across the Go and Temporal workflows, the Node.js backend and the React frontend.

2023 to 2026

Buidly

Senior Full Stack & Blockchain Engineer, technical lead on projects

I architected Surflux, a Rust indexer and streaming API for real-time trading data on Sui DeepBook, which handles 1,000+ events per second with sub-second latency in production. I compared Tokio channels with Redis Streams, built the SSE streaming layer on Redis Streams, plus active/standby failover and usage tracking for credit-based billing. I owned the architecture on 5+ projects and led two developers on several of them.

2015 to 2023

Pitech+Plus

Full Stack Developer, then Tech Lead from 2021

I owned the architecture and technology decisions for web apps, REST APIs and microservices, and mentored 4+ developers. From 2020 I worked on Nickis, a marketplace for children's clothes, and from 2022 I also did its DevOps. At Pitech+Plus I set up a production Kubernetes cluster on AWS from scratch, built the marketing email pipeline on SQS that sent 50,000+ emails per campaign, and improved MySQL query performance by up to 200%.

2015 to 2021

Freelance

PHP and Rust on the side

First on Upwork and then directly with clients. I built the first version of what is now welpe.de, a German platform for dog owners and dog services, including Stripe marketplace payments, plus around 3 Symfony and API Platform projects for another client. From 2021 I also worked on Elrond (now MultiversX) projects, with Rust smart contracts and NFT and ESDT tokens.

Also on GitHub

A Rust encoder that turns Dolby Atmos master files into Dolby Digital Plus Atmos, with 100+ stars, and an AI testing framework in progress.

See the open source work

More background on the about page.

If you think your product fits

Send me an email with what you're building, where it is today and which of the three roles you have in mind. I read all of them.