How a project actually runs
Three steps, no ceremony: understand the problem, put something real in front of you fast, then ship it and keep it healthy.
Most development processes exist to coordinate a team. Mine doesn’t have to, because there isn’t one — I design, build, ship, and maintain the whole thing myself. What follows is the entire method, and it’s short on purpose.
01Listen
The first call is 30 minutes and it is not a sales call. I want three things out of it: what you’re trying to make true in the world, who it has to be true for, and what happens if it isn’t true by a particular date. Everything else — stack, hosting, whether it’s native or web — is downstream of those answers, and I’d rather decide it after I understand the problem than before.
In practice a kickoff call covers the user you’re building for and the single action you need them to take; the systems this has to talk to (Stripe, Salesforce, HubSpot, NetSuite, a carrier API, an internal database nobody has documented); any constraint that is non-negotiable, such as a launch date, a security review, a HIPAA or SOC 2 obligation, or an App Store deadline; and what already exists, including the half-finished codebase you’d rather not mention.
Then I push back. The most valuable thing that happens in the first week is usually a feature getting cut. If something in the scope is going to triple the build time and serve five percent of your users, I’ll say so before it’s built, not after it’s billed. You leave that call with a shortlist of what ships first, what waits, and roughly how many days the first shippable version takes — priced by the day, so you know what a day costs before it starts.
02Build
“Something real in week one” is a literal commitment, not a slogan. It means that within the first few working days there is a URL or a TestFlight build you can open on your own phone, with the core path wired end to end: real data in a real database, real auth, deployed to real infrastructure. It will be ugly in places and it will be missing features. It will not be a mockup, a prototype, or a clickable Figma file, because those tell you nothing about whether the thing actually works.
After that it’s small, shippable steps. I work in vertical slices — one complete feature from interface down to database — rather than building a whole back end for three weeks and hoping the front end fits. You see progress continuously, and if a slice comes back wrong we’ve lost a day, not a month.
Day to day, you message me directly. There is no account manager, no ticket queue, no status meeting whose only purpose is to generate a status. I send what changed and what’s next; you tell me what’s wrong. Design comes with the build, so you don’t need to bring a designer, and the code stays readable for whoever picks it up after me — including you, if you hire in-house later.
03Ship & iterate
Shipping means production: hosting, domains, SSL, CI, environment variables, monitoring, and — for mobile — App Store and Play Store submission, including the metadata, the screenshots, and the back-and-forth when a reviewer rejects the build for something ambiguous. I handle that part. It is one of the most common places a project stalls when it’s handed back to a founder at “code complete.”
Then I watch it run. The first days after launch are where you learn what you actually built: which flows people abandon, which integration retries, which endpoint is slower under real traffic than it ever was in development. I fix what breaks and sharpen what works, and I’d rather find those things from logs and error tracking than from a customer email.
Ongoing, the 20-minute rule applies: anything that takes me under twenty minutes is free, forever, for as long as your thing is running. Swap an image, fix a typo, change a price, tweak a label — just ask. You obviously can’t stack twenty of them into a whole feature, and genuinely new work gets quoted like normal. But you’re never getting an invoice for a typo. The point is that your codebase should compound rather than rot, and small fixes should never be the thing standing between you and a better product.
What this costs and what’s included
Work is priced by the day, never by the hour. You can’t build anything good an hour here and an hour there — a full day of focus is the smallest unit that produces something real, so that’s the unit. No timesheets, no estimate that quietly doubles halfway through. A day covers design and interface, the whole build front to back, every screen it needs to run on, getting it live in production, integrations with whatever you already use, store submission where relevant, and a direct line to me.
Because I take a small number of projects at a time, most builds finish in fewer days than people expect. Tell me what you’re building and I’ll tell you how many days it takes.
What I need from you
Very little, but it has to be real: a decision-maker who can answer a question within a day, access to the systems the product has to talk to, and honesty about the constraint you’re least happy about — the deadline, the budget, the legacy system, the compliance review. Projects rarely go wrong because of the code. They go wrong because someone hid a constraint until it was expensive.
More about who’s behind this on the about page.