Build a product
SaaS products, internal tools and web applications for small businesses and non-technical founders. I work out the smallest version worth building, build it, and stay responsible for it when real users arrive.
The starting point
Most products I'm asked to build start from a problem the business already lives with, not from a specification.
01 / A real problem
Your customers or your team run into it every week. You need someone who can turn it into software without assembling a team first.
02 / Outgrown tools
What started as a workaround is now how the company works, and it has become the bottleneck. An internal tool built around the real process replaces it.
03 / A proven idea
A no-code version or a prototype showed that people want it. Now it needs accounts, payments and data that hold up. If the app already exists and half-works, Rescue is the better starting point.
04 / Connected systems
The value is in the connections: a payment provider, a booking calendar, a partner's data feed. Those are the parts that fail in production, and the parts I design first.
Process
How a product gets built from scratch. Each step starts with a written estimate and ends with something you can see.
Step 01
We start from the problem. I write down who the product is for, what it has to change for them and what the first version will not do.
Step 02
I define the smallest version worth building, the data model and the architecture, and give you a written estimate for the first step.
Step 03
I build in short steps. Each one ends with something you can open and use, not a status report.
Step 04
Tests, deployment, logging and alerts go in before real users do. The product should keep working without permanent dependence on me.
You describe the product in a few sentences: who it is for, what problem it solves and what exists today. I come back with the smallest first version I would build and a written estimate for the first step. From there, you decide whether we build it.
Core capabilities
What a product is made of underneath. I take technical ownership of all six, from design through to production.
01
REST APIs, service boundaries, domain logic, validation, authentication and integrations.
02
Payment flows, webhooks, user identity, permissions and failure handling.
03
Reliable asynchronous processing, retries, dead-letter workflows and workers.
04
Systems for operations, support, reporting, administration and workflow control.
05
Product interfaces connected to real backend logic, not only static frontend screens.
06
External providers, messaging platforms, CRMs, billing systems and internal services.
How we work together
You work directly with the engineer who reads and writes the code. No account managers, no juniors in between.
01
Repositories, servers and accounts stay in your name. I work with the access you grant, so nothing depends on me holding the keys.
02
If the project needs one, send your NDA and I sign it before we go into details.
03
Each step starts with a written estimate of what it covers and what it costs. After each one you decide whether to continue.
04
Every estimate and every invoice is in US dollars.
05
My working hours overlap with business hours in both the US and Europe.
06
Every request gets an answer within one working day, including the ones where the answer is that I am not the right person.
FAQ
No. A description of the problem, the people who have it and what exists today is enough for the first conversation. Writing down what the product does is part of my work.
You do, from the first commit. The repository, the servers and the accounts are in your name.
Yes. AI agents write much of the code inside boundaries I set. Product decisions, architecture and production quality stay with me, and nothing reaches production without my review.
Under the hood
These are the problems I have actually had to answer, and how I answer them. They are also the reason I write my own tools.
Problem 01
The payment provider stops answering in the middle of a charge. Did the customer pay or not? Retry blindly and you may charge them twice; give up and you may lose the payment. I build the system so every payment attempt carries a unique key: if the same request comes in again, it gets the first result back instead of creating a second charge. Balances are calculated from the full history of transactions, so a retry can never double them.
Problem 02
Payment providers and other services confirm events with automatic notifications (webhooks). In practice those arrive twice, in the wrong order or hours late, and the sender considers that normal. So the system never trusts a notification on arrival: it checks who sent it, saves it, filters out duplicates and only then acts on it. Its own outgoing notifications retry a limited number of times and then land in a review queue instead of hammering the receiver forever.
Problem 03
When responsibilities are not clearly divided, every change starts breaking something in an unrelated place, and eventually nothing can be updated safely. My rule is simple. The entry point of the system only checks and routes requests. Every business decision lives in the one part that owns the relevant data. If two parts fight over the same data, the split is wrong, and I fix the split.
Problem 04
An update can be pushed to the receiver instantly, but if the receiver happens to be down at that moment, it is gone. So I save every event first and deliver it second. The saved record is the source of truth: delivery can be retried, and anything that was missed can be sent again later. This is exactly how AlertLoop works.
Problem 05
When something fails in the middle of the night, a log line that just says "error" helps nobody. I record every step of a request under one shared id, so the whole story can be read from start to finish instead of being pieced together from fragments. And when an external service goes down, it switches off one feature, not the whole product.
The pattern
The happy path is the easy part. What separates a demo from a product is what happens on the second attempt, the duplicate delivery and the provider that stops answering.
Technical focus
I'm not tied to one stack. These are the tools I reach for by default, because I know how they behave under load and how they fail. But the system's boundaries matter more than the language it's written in.
Observability
Most production incidents are not hard because the bug is subtle. They are hard because nobody can see what happened. Logs are scattered, the delivery that failed left no trace, and the only evidence is a customer saying it didn't work.
I got tired of rebuilding the same two pieces on every project, so I published them. Traceloom connects related events into one readable timeline grouped by trace. AlertLoop makes sure the events that matter actually reach a human, with retries, dead letters and replay when they don't.
Both are open source, and the code is there to read and run. They are the clearest evidence I can offer of how I build.
Describe it in a few sentences: who it is for, what problem it solves and what exists today. Within one working day I'll tell you whether I'm the right person to build it and what the first step would be.