Internal tools shouldn't take a quarter
· The Launchpad crew · 3 min read
Every company has a list. The onboarding checklist that lives in someone's head. The approvals flow that runs on email and hope. The report that takes an ops manager half a day each month because it's assembled by hand from three exports.
Each item on that list is a small web app waiting to exist. And each one stays on the list, because the honest estimate for "small web app, live, with a login" at most companies is a quarter: a project, a budget line, a contractor, and a queue.
The build was never the slow part. The path from "built" to "live" was.
Why the quarter happens
Watch an internal tool die and you'll see the same stages:
- Someone needs it and describes it well.
- Someone else could build it in a few days.
- Then: which server? Whose cloud account? Who sets up the database? Who's on call for it? Who owns the domain?
- It becomes an IT ticket, then a project, then a quarter.
Stage three is pure overhead. None of it makes the tool better. All of it makes the tool later, and "later" is often "never", because the person who needed it finds a workaround and the moment passes.
Days, not quarters
Here's what the same tool looks like when the infrastructure question has a fixed answer.
Day one. You open Claude Code in the Claude desktop app, switch on the Launchpad connector, and describe the tool. A dedicated server with nginx and MySQL is live before you've finished writing the second paragraph of requirements. Claude builds the first version against it. By the afternoon there's a URL you can send to the two people who asked for the tool.
Day two. They use it, and they have opinions. You paste the opinions into Claude Code. Claude changes the code, runs the migration, restarts the service and checks the logs. The URL doesn't change.
Day three. It's in use. It has a database, backups and a subdomain. The "who's on call for the server?" question has an answer: not you.
The difference isn't that the app got easier. It's that the environment was already there, already safe, and already connected to the tool you build with.
The safety question, honestly
The reason companies put a ticket queue in front of "spin up a server" is a good one: unsupervised servers become liabilities. Someone leaves, the box keeps running, nobody knows what's on it.
Launchpad's answer is structural. One app, one server, one owner, one flat price. Access is via short-lived certificates that are issued, logged and revocable. The server has one public address on our domain. There's no shared account to sprawl across. If the tool is retired, the server is terminated and the line item disappears with it.
That's a much easier thing for a small business to say yes to than "give the new hire admin on the cloud account".
What to build first
If you're wondering where to start, pick the thing that meets all three of these:
- Someone asks for it every week.
- It's currently a spreadsheet, an email thread, or a person's memory.
- It would be obviously useful with one screen and one table.
That's the ideal Launchpad project. It'll take days, not a quarter, and once it's live, the next one on the list gets a lot more likely to happen.