Infrastructure for impact orgs in 2026: a founder's guide

August 21, 2026 · Restorative · 7 min read

The five stages from Lovable prototype to Google Cloud, explained without the jargon, for founders at impact organisations building a platform without a technical background.

This is for founders and directors at impact organisations who are building a platform without a technical background of their own. You'll recognise the moment: the thing you built works, people are using it, and the tooling that got you here has started pushing back. This is the road as I'd map it for 2026, with the jargon translated as we go.

Stage 1: Build the first version on Lovable

Lovable is an AI app builder. You describe what you want in plain English and it writes and hosts a working web app for you. No code on your side.

The free tier is better than it has any right to be, though it's a slow burner: you get a handful of build credits a day, and each meaningful change costs one. Paying removes that ceiling, and past the subscription all you need to buy is a domain name.

If your product needs AI features of its own (a chat assistant, a summariser, something that reads documents), that side basically integrates itself. One thing to plan around: build credits and AI credits now come out of a single shared pool. If your users burn through the AI side, you can find yourself unable to build, and the reverse holds too. Watch that number the way you'd watch a bank balance.

If Lovable doesn't suit you, try Macaly and don't think twice about switching.

Stage 2: Sailing from prototype towards MVP waters

Your app stores things: user accounts, records, uploads. At the start that lives inside Lovable, where you can't see much of it.

Connecting your own Supabase account fixes that. Supabase is the filing cabinet behind your app: the database, the file storage and the login system, in one place you can open and look inside. You'll want that visibility the first time a funder asks how many organisations signed up last quarter and you have no way to answer.

Stage 3: Leaving the walled garden

Around here you'll start seeing things on your frontend you don't like and can't influence. A Lovable favicon (the tiny icon in the browser tab) is usually the first one. Small, but it's your brand sitting in someone's tab next to nine others.

The jump to Claude Code is a leap of faith more than a totally different workflow. Claude Code is an AI that works directly on your project's files instead of inside a builder's interface. You still describe what you want in English. You get the whole thing, favicon included.

Two pieces come with it.

**GitHub** is where your code lives, with a full history of every change and who made it. It's the master copy. If a laptop dies, the organisation doesn't.

**Vercel** is what puts the site on the internet. You connect it to GitHub once, and it republishes every time the code changes.

You can ask Claude Code to set all of this up, and it will. Git, the change-history system underneath GitHub, is the piece that looks frightening, with its own vocabulary of commits and branches and merges. In practice, DNS will cost you more hours. DNS is the internet's address book, the thing that makes your domain point at your site. Changes to it don't take effect everywhere at once. You'll change a setting, see nothing happen, change it back, and discover the original was correct all along. Set it, then leave it alone for a few hours before touching anything.

Stage 4: Bring in the tech person

Once this setup starts feeling small and limiting, hire. Many organisations reach for a CTO. At this size the person who fits is a founding engineer with a CTO title: someone who builds, day to day, rather than running a department.

That works well, up until cap table talks. That conversation, where equity and dilution and investor terms are on the table, is where you find out which one you hired. Some people walk into that room and hold their own. Some are visibly out of their depth, and you'll know inside ten minutes.

Without a tech person, this stage still looks doable. Don't. Everything after this point compounds. The choices made here are the ones you live with for years, and unpicking them later costs several times what making them well costs now.

Stage 5: Move to Google Cloud

Three things arrive together at this stage.

**Observability** means being able to see what your system is doing: what's slow, what's failing, what a user actually hit at 4pm on Tuesday when they emailed you.

**Governance** means controlling who can reach what, and keeping a record of it. If you handle beneficiary data, funder data, or anything covered by a data processing agreement, this stops being optional.

**Scale**, and the bills that come with it. By now you're paying for Lovable, Supabase, Vercel and a domain, and the total has stopped being a rounding error.

I've tried all top 3 cloud providers and I recommend Google Cloud, specifically through the Google for Startups programme, which comes with credits that offset a real chunk of your migration year.

What moves:

Your app: Vercel to Cloud Run

Cloud Run runs your app and scales it with demand, including down to nothing when nobody's using it, which is most nights. You also finally get separate environments: development, staging, production, beta, and an investors-only instance you can demo from without touching anything real. That last one alone is worth the move.

Your database: Supabase to Postgres

The same underlying database, run properly. You'll be happy to let RLS go in favour of IP allow lists. RLS (row level security) is a set of rules inside the database about which user can see which rows. It's clever, and it becomes difficult to reason about once a few dozen rules interact. An IP allow list is coarser and much easier to hold in your head: only approved machines can connect at all.

Your files: to Cloud Storage

Uploads, documents, images. They move from Supabase into Google Cloud Storage buckets. Cheap, boring, and the least eventful part of the whole migration.

Your edge functions: the biggest refactor

Edge functions are small pieces of code Supabase runs on your behalf: send this email, process this upload, check this permission. You'll have accumulated more of them than you think.

The popular advice is to turn each one into its own microservice, meaning each becomes a separately built, deployed and monitored mini-application. My experience is that this is mostly the best way to maintainability hell: thirty small things to update, thirty places to look when something breaks, and nobody who knows all of them.

I'm building a coherent API layer instead. One front door, with clearly labelled endpoints behind it. New functionality goes in as a new endpoint. Existing edge functions get rewritten as routes in the same layer.

The switchover is where you avoid drama. You run shadow traffic first: a copy of real requests goes to the new endpoint alongside the old one, and you compare the answers. Users see nothing, because the old path is still the one serving them. Once the new endpoint has matched the old one under real load, you switch traffic across and delete the edge function. Nothing is ever switched off blind, and when a new route is wrong you find out from a comparison instead of from a customer.

That's the beauty of the strangler pattern: the new system grows around the old one and replaces it a piece at a time. It's my next 2-3 months.

And that's about it

A neat (and neatly biased) roadmap to building infra for your new impact org. Fits within 8.000 characters and will do the job despite the fact your tech friend potentially having other preferences.