There are three numbers on the front page of this site. They are accurate, and they are close to the least interesting thing about the work behind them. A total tells you that something happened. It does not tell you how, or what it cost, or which parts I would do differently.
This is the first post, so it is the one where I fill in what those numbers leave out, and tell you what you are signing up for if you stay.
What I have built
The two companies linked on the front page, Dealmela and Vetripath, are ones where I wrote the entire stack myself. Database, backend, frontend, deployment, the servers they run on. I am a co-founder on the business side of both, but the code is mine end to end, which is a specific kind of experience and a specific kind of exhaustion.
A set of iOS apps that I designed and shipped over the last year: Tend, for counting the things you are trying to do more or less of. Ebb, for cycle tracking. Pack Pilot, for packing without forgetting the charger. Small, careful apps, built in Swift, most of them solo from blank project to App Store.
And a long tail of smaller tools that I do not attach my name to. They are unglamorous, they solve one problem each, and between them they are most of the reason that user number is what it is. I will write about the engineering behind them and the things they taught me about distribution. I will not be linking them.
How I actually work
Alone, and across the whole stack. I design it, build the backend, build the frontend, deploy it, and answer the support email when it breaks. That is not a boast about productivity. It is the constraint that shapes everything I have to say, because every decision I write about was made by someone who also has to maintain it at 11pm.
The current tools: Go and Next.js, Postgres and Supabase, PocketBase when a project wants something lighter, Cloudflare in front, Dokploy on my own VMs rather than a platform that bills per request. Swift for anything on a phone. This site runs on that stack too, and I will write up how it is put together.
I am not loyal to any of it. I have rewritten enough things to know that the stack is rarely the reason a product works or does not.
Why I am writing now
For years my approach was straightforward: build the thing, put it in a store, go quiet, repeat. It worked well enough that I never questioned it. Products found users, users kept using them, and I never had to explain myself to anyone.
The problem with building quietly is that you end up with a decade of experience and no way to show it. Everything I know lives in private repos and in my own head. When I ship something new, I start from zero attention every single time, because I never built anything that compounds.
So this is me doing the thing I avoided. Writing it down, in public, under my own name, on a domain I own.
There is a selfish reason too, and I would rather say it than pretend otherwise: I want people to find my apps, and I want to talk to other people who build things. Writing is the only thing I have found that does both.
What I will write about
Three recurring subjects, roughly in this order of how often they will show up.
Build. Engineering, with specifics. Real problems from real products, with the code and the tradeoffs. What I chose, what I rejected, and what it cost. Not tutorials for things that already have good documentation.
Distribute. How software actually finds the people who need it. This is the rarest thing I know and the thing I get asked about least, which is backwards. Most of my users came from places that have nothing to do with launches or marketing budgets, and that mechanism is worth writing down properly.
Operate. What running products by yourself is actually like. Pricing, support, churn, the maintenance that nobody puts in a launch post, the moment you realise a feature you shipped is now yours forever.
Occasionally something that fits none of those, because I found it interesting and this is my site.
What I will not write
No listicles. No “ten tools you need in 2026”. No advice for a stage I have not reached, and no strategies I have not personally run. If something failed, it goes in with the number attached, because a post that only contains wins is a sales page wearing a blog’s clothes.
I am also not going to publish anything I would be embarrassed to have a better engineer read. That is the actual bar.
How often
One post a week.
I picked weekly deliberately, over something safer like monthly. A weekly commitment changes how you work: you start noticing the interesting problem on Tuesday instead of trying to remember one at the end of the month. The writing gets better because the material is fresher, and the work gets better because I am paying closer attention to it.
Some weeks it will be a substantial piece. Some weeks it will be a short field note about a tool or an API I tried. The floor is that something appears.
Who this is for
If you build software by yourself, or you are trying to, this should be useful. Everything here is written from inside the work rather than from above it, which mostly means the details are specific and the conclusions are smaller than the ones you get from people who write about building more than they build.
If you would rather talk than read, my email is on the contact section and I am on X for the shorter stuff.
Next week I will start where the story actually is, with distribution.