Buy for Speed, Build for Cost: Turning a Side Project Into a Live AWS Business in Five Weeks

Earlier this month I was at the AWS AI in Practice meetup in London. Plenty of good sessions, but one took the most ordinary premise imaginable, a partner who wants to start a dog-training business, and turned it into a clinic on shipping a real, revenue-generating product on AWS without quitting your day job.

The speaker, Damien Jones (AWS Consultant at Steamhaus), had a hard deadline: back-to-back appearances at Crufts. The first commit landed on 26 January; Crufts started in the first week of March. Five weeks on paper, but realistically a string of lunch breaks, evenings, and weekends. The business, Wolfie & Friends,  needed an online platform to take bookings and payments, and it needed to exist before the show.

Here's how the build went from an empty repo to a live business, and the decisions worth stealing.

Every online business needs the same three things: a domain, a website, and email. On top of that, Wolfie & Friends committed to three features, a contact page, a bookings platform, and payments.

The organising principle for the whole build was a single rule:

Applied to the project, that split out cleanly:

The reasoning behind each split is the useful part. Email is a solved problem, nobody should be writing their own mail platform in 2026. Payments carry real risk and compliance overhead, so a vendor owning the CI/CD, testing, and edge cases is worth paying for. Crucially, none of these are differentiators,  no one books a dog trainer to admire the payment flow. The website and contact page, by contrast, are exactly where the business gets to look like itself, and they're cheap and fully customisable on AWS.

This also killed the obvious SaaS shortcut. A Squarespace site at £12/month means the business operates at a loss before its first customer. WordPress is cheaper but boxes you into its widgets the moment you want something custom. Going pay-as-you-go and serverless on AWS meant near-zero fixed cost.

The build leaned on two AWS tools - CDK for the infrastructure and Amplify for the website.

The pitch for IaC here wasn't the usual DevOps sermon; it was purely about speed. It's declarative (tell AWS what you want and it sorts the ordering,  VPC before EC2, and so on), iterable (change a runtime or memory value as a number, not a console click), and reusable. Several existing side projects fed code straight into this one, including vetted patterns from AWS Labs repos that already sit inside the Well-Architected guardrails.

Amplify earned its place by handling the parts he didn't want to think about: the CloudFront distribution, the S3 buckets for site assets, and, a detail even he didn't know about until recently, Shield. Less to express in CDK, more time saved.

This is where it got current. The talk had previously featured Amazon Q Developer, but AWS announced its end-of-support on 30 April 2026, existing accounts keep working, but no new ones, and it's being sunset within twelve months. So the spotlight moved to Kiro.

Kiro is AWS's spec-driven IDE, a fork of VS Code with its own approach. Instead of a synchronous back-and-forth with the model, you describe what you want and it works through it deliberately. For a feature like the booking integration, that produced three documents before any real code:

It still has a "Vibe" mode for the chat-first, iterate-as-you-go style if you want it. The biggest single time-saver across the whole project was handing Kiro the entire Amplify front end - the speaker has a decade-plus in data but had never done web dev - along with a generated test suite.

The setup spans two AWS accounts in a personal org. A Networking account holds nothing but Route 53 (all DNS records in one place, by design). A Wolfie & Friends PROD account holds the Amplify deployment and the CDK resources, both living in the same GitHub repo with deploy behaviour driven by GitHub Actions.

The request paths are clean:

For bookings, the buy decision landed on Cal.com - less famous than Calendly but API-driven, with a generous free tier and a clean React embed component. Notably, Kiro read Cal.com's docs itself to understand the schemas and auth; it was only told what to do, not where to look. For payments, the same logic pointed at Stripe - API-driven, with all the payment complexity owned by someone else.

This is the bit that makes the whole thing land.

The live platform runs on 16 AWS services, across 106 commits and roughly 645 unit tests. And it costs almost nothing:

Against that, revenue from March to May came to £580 (£220 / £200 / £160) - roughly £200/month, from one class of around three people most weeks at £20 a head, minus Stripe's ~50p per session. Not paying off the mortgage, but a business that costs two dollars a month and brings in two hundred pounds is comfortably in the black, with more classes and venues being lined up.

Worth knowing if you're going to lean on it: Kiro meters work in credits, not tokens. Plans run Free (50 credits) → Pro $20 (1,000) → Pro+ $40 (2,000) → Power $200 (10,000), with $0.04/credit overage. A credit is "a unit of work" - simple prompts cost under one, spec tasks cost more.

The lever to watch is the model multiplier. Auto runs at 1.0x and usually picks a Sonnet model. The moment you choose a model yourself the maths changes - even picking Sonnet bumps you to 1.3x, and Opus roughly doubles your utilisation at 2.2x. It's not more money (the plan is fixed), but you burn the allowance faster. The honest framing: not "avoid the big models," just "know what you're spending."

Three I'm keeping:

Decide with confidence - align, define, commit. Make time for planning and don't rush the decisions, even if it means less time to build. A rushed call you discover is wrong three weeks in costs more than the planning would have.

Use what's already out there. IaC, serverless, and managed services are well-tested and let you move quickly and repeatably. Reusing code also means the AI isn't redoing work - it can just read what exists, which keeps credit usage down. And you can use familiar managed tools (like Amplify) to solve unfamiliar problems (like web dev): you may not fully understand the result, but you understand how you got there and how to repeat it.

Build something that actually matters. The best way to build something reusable is to build something that gets used. It's arguably never been easier to ship - and this one started a real business, off the back of lunch breaks.

If you're building anything on AWS right now, the buy/build split alone is worth writing on a sticky note. The interesting shift is that the "build" half - the differentiating, custom work that used to eat your five weeks - is now the part you can hand largely to spec-driven AI, while the boring-but-risky half goes to vendors. Five weeks, two dollars a month, live before Crufts.