This is the working method I shared in my talk, POC Graveyard. The talk was about why it has never been easier to start a project and never been harder to finish one. AI makes the first hour fast, surprising and rewarding, while the finishing work stays slow and mostly invisible, so we keep abandoning projects for the thrill of a new start.
This list is how I work around that. It is the order I follow on my own products, from first idea to something real people use. Take it, keep it, adapt it.
- Define done before you start. Write down what "done" means and what is not going into this version. Do it before the first prompt.
- Build very small, but build it well. Only the omelette.1 The little you have must be good enough to actually feel the product. The output of a single prompt usually isn't.
- GitHub immediately, Vercel soon after. The code is saved from minute one, and every big change starts from a point you can return to. Very quickly you have a live link you can send to someone.
- Get feedback as early as possible. If it's meant for other people, send the link or a landing page2 to friends and family. Find out whether anyone cares before you invest.
- Keep an idea parking lot.3 Every cool idea that comes up along the way gets written down on the side. It doesn't get built now.
- Eat the frog.4 Once you've decided this is a product for other people, deal with the dry parts right away, while motivation is high: login and auth, env files, API keys, the AI integration, and everything publishing requires (deploy, domain, settings). Leave them for the end and you'll meet them when you have no energy left.
- Resist feature creep.5 For every addition, ask: how much does this raise the value of the product? Most answers go to the parking lot.
- Iterate on the core. Keep working on the small thing until it does its job properly.
- Do the gray work.6 Accessibility, small screens, edge cases, error messages, testing. One gray task at the start, before the fun part.
- Ship, then add one piece. Skateboard, then scooter, then bicycle.7 One piece at a time: build, polish, test, release. Not twenty features at once.
- Be ready to pivot, and ready to quit. If users pull you in another direction, follow them. If the product isn't good, stop. Closing a project on purpose is also finishing.
- Done beats perfect. Successful products run into problems. And bugs. You need users to improve a product. Alone, you can't see everything.
- Turn lessons into Skills.8 A preference you keep repeating, a mistake you fixed twice: write it into a Skill. On the next project, the AI already knows.
This framework goes beyond app development.
In dev as in life:
- Be kind to yourself.
- Celebrate small wins.
- Set reasonable expectations.
Getting things done is a muscle. The more you finish, the more comfortable you get with delayed gratification. Finishing starts to feel rewarding in itself, not just starting. And the reward loop shows up again, this time in a way that serves you rather than hurts you.
Notes
The omelette. In the talk I compared an ancient spatula with a modern one. The modern one has silicone, colors, a hanging loop and ergonomic design, but both exist to do one thing: flip an omelette. Your omelette is the single thing your product must do. Without it, nothing else matters. ↑
Landing page. Every product of mine that has users today started as a one-page site explaining the problem and the solution. The reactions told me whether a full app was worth building. ↑
Idea parking lot. One file where new ideas go. A new idea is tempting because it promises the excitement of a fresh start. Writing it down means it isn't lost, which makes it much easier to let go of for now. ↑
Eat the frog. A saying popularized by Brian Tracy's book Eat That Frog!: do the most unpleasant task first, and the rest of the day is easier. For me, the frog is all the dry setup and publishing work. ↑
Feature creep. The slow pile-up of "just one more feature" that keeps moving the finish line. Each new feature feels like progress because it brings back the excitement of starting, but it also adds testing, bugs and edge cases. ↑
Gray work. The unglamorous tasks that don't show up in a demo but decide whether real people can use the product. They are most of the "last 20%" where projects die. ↑
Skateboard to bicycle. From Henrik Kniberg's illustration of an MVP: don't deliver a wheel, then a chassis, then a car. Deliver a skateboard, then a scooter, then a bicycle. Every stage is something a person can actually use. ↑
Skills. Reusable instruction files that tell your AI tool how you like things done. ↑