Thinslices

A working internal tool can now come out of AI coding tools in weeks. Deciding when it can replace the spreadsheet the business runs on is the slower question. Here is how we answered it. hubs.li/Q04CyMq20

Our COO built the tool we run delivery and invoicing on, with AI and no developer background. First use took 6.4 weeks. The switch waited for a rule: three weeks with no differences from the old spreadsheets. hubs.li/Q04CyMxF0

No amount of preparation removes the risk from building something new. It can change who sees the risks before they surface: which were retired before the build, which were carried and who owns each one. hubs.li/Q04ByqNZ0

Building internal tools with AI again, we would still start with sign-in and the people list. Settle who can log in and who works in which role once, and every new tool starts with it on day one. hubs.li/Q04CyMWC0

Founders and development partners usually see different risks before a build. Engineers are often brought in late, so technical risks surface after the budget is set. Write down which risks were retired, which were carried and who owns each. hubs.li/Q04Byr6j0

AI-built internal tools look finished long before anyone can rely on them. What closes the gap: run old and new side by side, let a rule decide the switch and keep invoiced numbers in ordinary code. hubs.li/Q04CyMR40

Five questions to answer before a build budget is committed. Any question the founder or the development partner can't answer is where the remaining pre-build work should go. hubs.li/Q04ByqT20

Running a new tool beside the old spreadsheets sounds like a test of the new tool. For us it was just as much a test of the old ones: in June alone they disagreed by about 78 person-days. hubs.li/Q04CyMVF0

Not every product risk can be retired before the build. Some settle in a design phase, some with real users, some only after a release or once code runs. Only the first two come before the build budget is spent. hubs.li/Q04Byr610

AI has made software quick to build. It has not made it quick to trust. Our staffing and invoicing tool was in real use after 6.4 weeks. Retiring the spreadsheets it replaced took another 30. hubs.li/Q04CyMRY0

A product design phase can narrow product-market fit risk, but it can't close it. Whether customers will pay, and keep paying, only shows up after a first release. So name the one assumption release one is built to test. hubs.li/Q04Byr6p0

Most in-house vs development partner comparisons for an MVP stop at cost and control. A better question: which knowledge has to live inside from day one, which needs an in-house owner by launch and which can be rented. hubs.li/Q04BxFKS0

Moving an MVP from a development partner to an in-house team is far easier to plan before the build than after it. Five decisions made up front settle most of it, including whose name the repositories and cloud accounts are in. hubs.li/Q04BxFJB0

Even with a strong development partner, a few parts of an MVP can only come from inside the company. When nobody inside owns product decisions, they still get made, by whoever is writing the code that week. hubs.li/Q04BxFxW0

Engineering hires take 35 to 36 interviews each, against 22 to 24 for non-technical roles (Gem, 2026). For an MVP, that search competes with the runway. Start the in-house or partner decision with which knowledge you need to hold. hubs.li/Q04BxFpY0

Some product risks can be settled before the build. Others only show up with real users or running code. Four checkpoints, and five questions to answer before a build budget is committed. hubs.li/Q04BxwPk0

The day a partner hands over an MVP is the wrong day for your first in-house engineer to start. New engineers need time to ramp up, so the overlap between teams has to begin well before the partner steps back. hubs.li/Q04Bnmz-0

Engaging a product design agency before the groundwork is done wastes money and extends timelines. hubs.li/Q04spkNj0 Validated problem. Defined scope. Someone who can approve a direction without broad consensus.

Ask these before signing anything: 1. What happens when discovery shows the original direction is wrong? 2. How do you recruit real target users, not internal teams? 3. Who actually does the work, and are they dedicated or split across clients? hubs.li/Q04spnLV0

A clickable prototype can now be built in an afternoon, so looking finished proves very little. Four tests to run before one decides your build budget. Start with the first: ask to see what happens when something goes wrong. hubs.li/Q04zTkvl0