How a project actually goes.
Modern tools have made the building part fast, including prototyping and iteration. The slow parts now are the ones that should stay slow: security, the user experience, the moments where a small choice changes how the whole thing feels. The process is built to use speed where it helps and patience where it counts.
Once we start working together, we set up a shared Slack (or your preferred channel) that day. I'll share progress, ask questions, and send work to react to throughout the week. You'll always know where things stand.
These are the steps most projects follow. We can flex if yours is a special case.
Tell me about what you're working on. I'll ask the questions that help us both figure out whether there's something worth building, and whether I'm the right person to help.
A focused chunk of time to figure out what the thing should actually be. This is where we save the build from becoming expensive guessing: pressure-test the problem, turn the fuzzy parts into mockups, and decide what the first version needs to prove.
I turn the mockups into a real, deployed product. You'll see updates in our shared channel every day and we'll jump on a call once a week to talk through decisions.
After launch, I stick around. Bug fixes, small UX tweaks, and the answers to questions that only show up once real people are using it. For as long as it takes to land smoothly.
Modern speed, human taste.
AI-first tools make it possible to get a screen, flow, or rough demo in front of us quickly. That speed is useful, but it can also make weak ideas look more finished than they are. So the process uses AI to explore directions and test the shape of an idea, then applies human taste, product judgment, and technical care to decide what is actually worth building.
See projects shipped with this processFind the strongest shape. Sometimes that means a focused tool for one team. Sometimes it means a product with a wider market.
Cut what feels generic. If it could belong anywhere, it is not sharp enough yet. Good products feel specific, even when they are built to scale.
Make it hold up. Real data, real users, permissions, errors, edge cases, handoff. The good version has to survive the real world.
Common questions.
Who is this for? +
Founders and small teams who have a problem in front of them. Maybe an idea you can describe but can't quite ship. Maybe something living in spreadsheets, Slack threads, and copy-paste that needs to be real software. Either way, let's talk.
How much does it cost? +
We don't know until we talk, but most people are surprised how much fits inside their budget. Modern tools cut the time on the parts that should be quick. The careful work, the parts where mistakes cost real money, gets the time it deserves. We name the number before any work starts.
What about ongoing costs after launch? +
Not much, at the start. I default to scrappy, using generous free tiers where they work. Real costs show up only where they're unavoidable (a domain, an API key or two). Bigger infrastructure bills kick in when you're hitting scale, which is a good problem to have.
How long does it take? +
Small projects can ship in a couple of weeks. Bigger ones run longer. We'll pin down the timeline upfront, once we know what we're actually making.
How does AI actually show up? +
As leverage, not as the product manager. I use AI tools to move faster through exploration, code, debugging, and iteration. I still make the product decisions, review the work, and slow down around anything that affects trust, money, private data, or the core user experience.
How do you handle privacy, security, and ownership? +
I default to boring, established foundations: managed auth and storage where appropriate, least-privilege access, environment-managed secrets, version control, backups, clear account ownership, and code you can take with you. If the project touches regulated data, payments, medical information, or enterprise compliance, we name that early because it changes the scope and the stack.
Can we skip the planning step and just build? +
Sometimes, yes. If the scope is already clear and the moving parts are limited, I can quote and start right away. Most projects benefit from some upfront thinking together, because it makes everything that follows faster, clearer, and easier for both of us.
What if the scope changes once we're building? +
It happens. Small changes get handled inside the work. Bigger changes get named, discussed, and re-scoped before I move forward, so the bill never quietly drifts.
What happens once it's live, and after? +
I stick around while you get it out into the world. Bug fixes, small tweaks, real answers to questions that only show up once actual people are using it. When you're running smoothly, we wrap up cleanly. You own the code, the accounts, and the deployment.
Have a project on your mind?
That's the whole first step. A 30-minute conversation, no deck, no pressure.
– Domp.s.every one of these lands in my inbox, not a form queue.