Hire the engineer
who'll write the code.
I am a one-person product studio. I build and finish software for founders, and I build white label for agencies who need the work done under their name. AI, web, mobile, SaaS.
One senior engineer · A written reply within 24 hours · Remote from UTC+3
Two ways to work with me
Pick the one that sounds like you
What I do
Software built to work in production
Not demoware, not a pitch deck. The tools below are the boring, reliable choices, picked because they hold up after launch.
How I work
A one-person studio, on purpose.
I bring in another engineer when a timeline genuinely needs one. The default is a single senior person who holds the whole picture. Three things stay true either way.
The person who answers writes the code
No account manager, no handoff, no rotating developer. You talk to me, and I build it. The context stays in one head from the first message to the last commit.
I work inside your process
Your repo, your board, your review bar. I already work day to day inside a US company's engineering process, so shipping to a real team's standard is how I already operate.
I say no when I should
I turn down work I cannot do well, or cannot do on your timeline. You hear that early, not three weeks in. A fast honest no is worth more than a slow maybe.
The kind of thing I catch early
Judgment is the product.
There are no logos to show you and no case studies I can name. So here are two decisions that separate work that ships from work that gets sent back. Both are checkable. Follow the links.
Two rules that point in opposite directions
Apple guideline 3.1.1 says anything you unlock inside the app has to go through in-app purchase, though since 2025 US-storefront apps can also link out to other payment methods. Guideline 3.1.3(e) points the other way: goods and services used outside the app have to use something other than in-app purchase. Build a payment flow against the wrong rule and the app gets rejected at review, after the work is done. Knowing which rule a given feature falls under before writing it is the difference between shipping on time and a rejection you find out about a week later.
Apple App Store Review Guidelines, 3.1An index that scans thousands to return three
Firestore lets you put range filters on more than one field now, so the availability query a booking system needs will run. But only the first range field actually narrows what the index scans. The rest just filter the results after the fact. The query returns three bookings and reads thousands of index entries to do it, and since you are billed on index entries read, the cost shows up quietly once real data arrives. The fix is ordering the fields by how selective they are, which the docs spell out.
Firestore range and inequality filters, Google Cloud docsHow a project moves
Six stages, scoped to fit
A Sprint covers the first two. A Build engagement runs all six. A partnership cycles through them. I size the process to the engagement, not the other way around.
01
Listen
02
Map
03
Set up
04
Build
05
Ship
06
Iterate
Tell me what
you're building.
A short Sprint or a full build, it doesn't matter. Send a few sentences and I'll reply within 24 hours with a straight answer on whether I can help.
I read and reply to every message myself.