AI can build a replacement for a product like Toggl now. It can't do it in a weekend, and it can't do it from one prompt. It takes a few months, and it only works if you plan painfully well, test just as painfully, and play every role a product team used to fill.
This year at Ateko we built two internal tools that replaced commercial software:
- A Salesforce org monitoring tool. Three of us built it, mostly two, with me helping for the first few weeks.
- A project planning and time-tracking tool that replaced Celoxis and Toggl for our Salesforce practice. That one is essentially me. It started as a weekend personal project, and when I described it to a colleague it found a new direction as the replacement for the separate tools we used to plan projects and people's time and track progress. It now pulls commit activity from GitHub, pipeline from Salesforce, and staff and vacations from ADP.
Either one would conventionally take a product team of four to six people 12 to 18 months. We did each in three to six months of work.
How much faster, and with how many people?
About three times faster, with a much smaller team. A project that needed two to six people can now be done by one or two.
The rule of thumb I use for time: six months of work now takes six to eight weeks, and 12 to 18 months now takes four to six.
The headcount drop is the half of the gain people mention less, and on our two builds it was real: one tool was essentially me, the other mostly two people. It's also why the rest of this post matters. When the people go, the roles stay. Someone still has to be the architect, the manager, the QA, and the product owner, and on a team of one or two, that's you.
Those are big gains, and they're a long way from the 50x the "I built it in a weekend" posts imply. They're also conditional. The gain only shows up if you do the work in the rest of this post. Skip it and you get a fast demo that falls over when real use touches it. I made the earlier version of this argument in Stop Measuring AI by the Stopwatch, when the monitoring tool was four weeks old. Both tools are finished now, and the argument held.
What's the approach?
Plan until you and the AI agree, build a first pass, test it hard, check it against what you needed, and repeat.
- Plan. Read the plan, question it, and understand it before anything gets built.
- Build the first pass. It arrives fast and looks finished. It's a proof of concept.
- Test. Spend as much time here as you did planning, or more.
- Confirm the stories were met. Working and right are different checks.
- Repeat. Many times.
Each step maps to a role you'd normally hire for. With AI you're filling all four yourself.
The architect: plan until it hurts
Your job is to make sure you and the AI agree on what's being built before it builds anything. Read every line of the plan and challenge it.
What that looks like:
- Read the whole plan the AI proposes, not the summary.
- Question anything vague, and make it explain anything you don't follow.
- Push back and send it around again. A good share of my first plans come back changed.
- Write decisions down. When a plan changes later, record what changed and why.
Why it matters: if you can't explain the plan yourself, you and the AI aren't aligned, and everything it builds next inherits the gap. The mechanics I use (a rules baseline, requirements, decision records, phased delivery) are in Share More Context, Demand Less Genius.
The manager: the first build is a proof of concept
Your job is to treat the first pass as a starting line and run the iterations from there. It's where most people stop.
What that looks like:
- Take the first build for what it is: a PoC with real screens and real data.
- Decide what matters next, scope the round, and keep the AI on task.
- Make the AI do its own legwork. When an assistant handed me a ten-step checklist to verify its work, I pointed out that everything ran in Docker and it could run the steps itself. It did.
- Keep working notes so each session picks up where the last one ended.
Why it matters: the first pass is where the speed lives, and it's convincing. It isn't the product.
The QA: make the AI write the test cases, then run them yourself
Your job is to prove it works the way a real person will use it. That means test cases written by the AI and run by you, with screenshots.
What that looks like:
- Have the AI write a full test suite: every feature, where to test it, what to test, and what should (or shouldn't) happen, covering every situation.
- Work through each one yourself and report issues back with screenshots.
- Correct shallow or poor implementations, and suggest improvements while you're in there.
- Have the AI run the app end to end and screenshot every page.
- Ask the AI what you still need to test.
- Run a full security sweep before anything ships.
Why it matters: the AI will tell you it's done when it isn't. Two examples from my weekend build:
- It reported "Nothing was missed" on a Toggl data import. One screenshot showed a week with 12 hours the app had never seen.
- It reported 75 tests passing. Switching the calendar from day view to week view crashed the page.
The product owner: did it do what you needed?
Your job is to go back to each user story and confirm it was met, and to decide what's out of scope. After planning, this is the hat people skip most.
What that looks like:
- Walk each user story and confirm the build does what it promised.
- Cut scope on purpose. When I restarted the weekend tracker, most of my instructions were a list of what to leave out.
- Say "not good enough yet" when it isn't.
Why it matters: QA tells you it works. The product owner tells you it's the right thing. An AI that says "done" is reporting that it stopped, which is the agreement problem at product scale.
Where do people go wrong?
Most skip the planning and the deep testing, then trust the first answer.
- Asking for the whole thing at once: "Build me Toggl. Go." That's what social media sells. You can do it, but it takes time.
- Treating the proof of concept as the product.
- Accepting green tests and a "done" message as proof.
- Never going back to check the stories were met.
Let's be honest about the cost
It's slower and more tiring than the hype suggests, and it assumes you know enough to wear all four hats.
- It's uncomfortable. The hours go into reading plans, clicking through screens, and writing up defects.
- It leans on experience. Knowing what a weak plan looks like comes from years of shipping software. Without that, make the AI explain itself more, and expect it to take longer.
- It costs real money in credits. I put numbers on that in the last post on this.
- Not every task needs all of it. A one-line fix doesn't need a plan review and a full test pass.
Prompts to steal
Use these two at the end of every build round.
"Write me a full test suite for what you just built. For every feature, tell me where to test it, what to test, and what should (or shouldn't) be the outcome. Cover every situation, including the ones where it's supposed to fail. I'll work through each one and report back with screenshots."
"Did you test all of your work? I want you to thoroughly review everything you built and do hands-on testing of all of it before you tell me it's done."