Hey, I’ve been solo building a hyperlocal discovery platform for UK independent businesses, for about 8 months and some very long days. It’s still very much an MVP, but I’ve learned a lot from this project, even after 25 years as a developer, including when not to over-engineer things.
I am finally getting close now and plan to start rolling it out in the next few weeks. The platform is coming together very well now and the data is solid with load Speed tests over 92 in Vercel.

Posting this in case it helps anyone else building geo-heavy apps with Next.js.

Stack

• Next.js (App Router)
• Supabase (Postgres)
• PostGIS
• n8n (self-hosted)
• Vercel

No microservices. No queues. One main database. Very deliberate.

Why Next.js worked (and where it pushed back)

App Router + server components simplified more than I expected

I assumed I’d split out a backend pretty early. That never happened.

Using server components plus Supabase RPC calls let me:

• Keep data access close to the UI
• Avoid over-fetching
• Push heavy joins and logic into Postgres instead of Node

For locality pages (town + category), this ended up cleaner than running a separate API layer.

Takeaway: if your backend is mostly data access and composition, Next.js can carry you a long way.

The real bottleneck was Postgres, not Next.js

My first pass at geo queries was bad:

• Distance calculations over large tables
• No spatial indexes
• A lot of “just make it work” SQL

Once I:

• Added proper GiST indexes
• Used bounding-box + refine patterns
• Moved logic into RPC functions

…query times dropped dramatically.

Takeaway: if location queries feel slow, it’s almost always your SQL.

n8n quietly became core infrastructure

n8n started as “temporary glue”.

It now handles:

• Business ingestion and enrichment
• Onboarding / Business verification process
• Email discovery workflows
• Sponsor rotation and fairness logic
• RSS ingestion → structured content

That let me avoid standing up workers, queues, or cron services early on.

Takeaway: boring automation beats bespoke systems at this stage.

Things I’d do differently

Design read paths earlier

The app is heavily read-biased (lists, feeds, discovery pages).

I waited too long to:

• Pre-aggregate data
• Use materialised views
• Treat read queries as first-class citizens

It worked… until it didn’t.

Lesson learned: if your product is read-heavy, optimise for reads early.

Be stricter about data contracts

I now enforce:

• Slug-driven routing only
• ID-only joins internally
• Zero string-based joins in app logic

That alone killed a whole category of bugs around ghost pages and mismatched data.

Rule of thumb: URLs are presentation. IDs are truth. Never mix them.

I flirted with microservices far too early.

In reality:

• One Next.js app
• One Postgres database
• One automation layer

…has been much easier to reason about, debug, and evolve.

Questions for the community

1. Anyone running PostGIS with Next.js at scale — any indexing patterns you swear by?
2. For read-heavy apps, when did you introduce read replicas or separation?
3. Anyone using n8n long-term in production? Where did it start to creak?

I’m launching a Manchester pilot soon and expanding town-by-town after that.

Happy to share some deeper details if useful.