If nothing bad happens when the software stops working, build it yourself with Claude. If a customer gets double-billed or a job gets missed when it stops, hire someone.
I use Claude every day, and it writes a lot of the code I ship. So I’m not going to tell you it can’t do the work. It can write you a website or a small app, and it will probably run the first time you try it.
Getting it to run is the easy part, though. The hard part starts a few months later.
Plenty of work doesn’t need me, and I’d tell you the same thing on a call. Some of it is worth doing in Claude this afternoon:
If that covers what you need, keep your money.
Say you ask Claude for an automation that sends an invoice when a job is marked done. You’ll get one, and it will work on your test job.
Now someone marks a job done, changes their mind, and marks it done again. Does the customer get two invoices? What if the invoicing service times out halfway through the request? What if a job gets reopened after it was paid? Those cases decide whether the thing is safe to leave running, and you only get an answer if you knew to ask.
I spent most of the last six years on payments teams, and most of that work was questions like these. Claude is good at them when you bring them up. It’s the bringing them up that takes experience.
A wrong answer from Claude looks exactly like a right one. It comes in the same confident tone, and the demo still works. If you can’t read the code, the demo is the only evidence you have.
That matters most for problems a demo won’t show you. A web form with no protection against spam still submits fine. A secret key sitting in a page’s code still works, and anyone who views the page can read it. A customer list behind a link with no login still loads when you click it.
If your software handles card numbers or health records, there are rules about how it has to work, and they apply no matter who or what wrote it. Talk to someone who knows them before you build.
Software that depends on other services breaks without anyone touching it. Your booking tool renames a field and the automation quietly stops. You find out at the end of the month, when the invoices never went out.
Claude can help you fix that, once you notice. But you’re the one who has to notice, and you’re the one logging into the hosting account at 9pm to find out why your email started landing in spam. You’ll also be keeping track of every service it runs on, in accounts you set up a year ago and half remember.
That’s the real cost of doing it yourself, and it’s easy to miss because Claude makes the first day feel free. At $35 an hour, the $199 automation plan comes to under six hours of your time a month. If you’d spend less than that looking after it, and you like the work, doing it yourself is a reasonable choice. Most owners I talk to would rather spend those hours on the business.
Build it yourself if all of these are true:
Bring someone in if any of these are true:
There’s one more reason to do it yourself. You might want to own the code. With Foundry24, your domain, content, and data are yours, and the website is yours after 12 months. The code behind an automation stays with me, and it stops when the subscription does. If owning it matters more to you than not having to look after it, that’s a good reason to build your own.
Build the rough version in Claude and bring it to the call. A prototype shows me what you want better than any description, and you’ll have learned which parts you care about. I might rebuild it rather than keep it, but you’ll get a better spec for having made it.
It starts with a 30-minute call. You’ll come away knowing whether this is worth paying for, and sometimes the answer is that Claude has it covered. If it is worth doing, you get a one-page spec with the monthly price on it. Every price is on the plans page.
Yes. Either one can write a working site and walk you through putting it online. You'll still own the hosting, the domain, the email records, and whatever breaks later, so it suits a business with the time to look after those.
When the software touches money or customer data, when customers depend on it, or when it runs with nobody watching. A mistake in those places costs more than the developer does, and it's hard to spot if you can't read the code.
Many do. Robbie at Foundry24 uses it every day. The tool writes the code quickly either way. The difference is knowing what to ask for and being able to tell when the answer is wrong.
Yes, and it helps. A rough prototype shows what you want better than a description does. The finished version might get rebuilt, but the prototype makes the spec better.
AI agents, automation, and websites, built in a few weeks and then maintained for a monthly fee. If something in your week should be software by now, book a call.