DEV Community: Lotus Tech Labs

Build vs buy: buy the commodity, build your edge

Lotus Tech Labs — Fri, 02 Oct 2026 20:46:39 +0000

Buy anything your competitor can also buy. Build only the thing they choose you for. That is the entire rule. Build or buy arguments run long because applying it honestly means admitting that your favourite internal project is a worse version of something you could rent this afternoon.

We build custom software for a living, so weigh the next part accordingly: most of what a company runs should not be custom, and a good share of what gets built in-house is a CRM that could have been rented for the price of a fortnight of engineering time.

Commodity and edge

A commodity is anything your competitor can buy on the same terms you can. A customer relationship manager is a commodity. So is payroll, email, error tracking, payments, and the database under all of it. Nobody has ever chosen a supplier because that supplier had written its own CRM.

Your edge is the part of the product a customer would notice if it disappeared. It is usually narrower than people expect, and it is almost never the part that was fun to build.

So when the question is whether to build something that already exists as a product, start by asking which of those two things it is. If a competitor can sign up for the same tool tomorrow, building it buys you nothing they cannot match in a day.

One product, and every call we made on it

We built a ticketing platform where event organisers onboard, create events, sell passes and scan them at the door. Here is what we bought, and the reason in each case was the same: a competitor could buy it too.

Payments. Razorpay. Payments is a commodity to us and a compliance department to them. Building it means holding card data and inheriting an audit.
Push notifications. Firebase. There is no version of this we could write that is better than the free one.
OTP over SMS and WhatsApp. Bought. Delivery to a phone network is somebody else’s relationship with carriers.
The database and cache. Postgres on Aurora Serverless, and Valkey. Managed, because the alternative is becoming a database administrator by accident.
Scaling. AWS auto-scaling. A scheduler is not a differentiator.

And here is the one thing we built: pass scanning that survives a venue with bad internet. Scans queue on the device and reconcile when the connection returns, without letting the same pass through twice. No product sells that for this use case, and it is the difference between a queue moving and a queue stopping at the one moment the client cannot afford it.

That is the shape of a healthy decision list. Five bought, one built, and the built one is the reason the product works at a real venue on a bad day.

The same rule inside an AI feature

On another system we built image similarity search over a library of roughly five million photographs, answering in under 200 milliseconds for about a million monthly active users.

We did not write a vector database. We used Qdrant, because a vector store is a commodity and a very good one is free. What we built was the part that is not: the embedding pipeline, the index strategy, the reindexing and the backfill. A vector database is something you install. Making five million images answer in under 200 milliseconds is something you design, and it is where every hour of that project paid for itself.

The same split holds for most AI work: the model and the store are bought, and the retrieval, the evaluation and the failure cases are built.

The two costs people get wrong

Buying: the sticker price is not the cost. The cost is per-seat creep as you hire, and the exit. Before you adopt anything your workflows will live inside, ask what leaving costs. Your data will be exportable, because every vendor says so. Your integrations, automations and the habits of the people using it will not be.

Building: the build is the cheap part. A thing you build is maintained for as long as the company exists. Somebody is on call for it. Somebody upgrades the dependency with the advisory against it. The person who wrote it leaves, and the next person spends a month learning what it does before they can change it safely.

A build is not a project. It is a hire you have not made yet.

That is the number missing from most build-or-buy spreadsheets. People compare a one-off build estimate against a recurring subscription, which is comparing the wrong two things. Compare the subscription against the build plus a decade of somebody owning it.

The hard case: when a bought thing becomes your edge

The rule is easy at the extremes and difficult in the middle, and the difficult middle is real. You buy something at twenty people because it is obviously a commodity. At a hundred people the workflow built around it has quietly become how the company makes money.

One marketplace we built for had the problem every marketplace has: vendors will not write their own listings, and an empty listing sells nothing. The answer was automation that turns a short prompt into the description, the FAQs and the imagery.

We did not build a workflow engine. We used n8n and built the prompt pipeline and the data mapping on top of it. The orchestration is a commodity. What the prompts do with that marketplace’s own data is not, and it is the part a competitor cannot copy by buying the same tool.

That is usually the answer in the difficult middle. Not build or buy, but buy the engine and build the part that is yours.

We applied this to ourselves this week

Our own contact address needed a real mailbox, somewhere we could reply from rather than just forward to. Three options: stitch something together free, pay a small amount for one provider, or pay a bit more for another.

The rule settled it in about a minute. Is email deliverability our edge? No. Can a competitor buy exactly the same thing? Yes, in four minutes, with a credit card. So we buy it, and we spend the saved time on something a client is paying for.

The useful part is the temptation we had to turn down. We are engineers. We could run a mail server, and some of us would enjoy it. That is exactly the trap: being capable of building something is not a reason to build it. The question is never whether you can.

It helps that the downside is lopsided. Getting email wrong means an enquiry lands in a spam folder, and one lost enquiry costs more than several years of the subscription. When the failure is that asymmetric, buy the thing with the best track record and stop thinking about it.

Three questions that settle it on a call

If we buy this, does any customer ever notice? If the honest answer is no, buy it. Internal tooling is not where you earn a reputation.
If this breaks at 3am in two years, who fixes it? Name the person. If they are not on the payroll yet, you are costing a hire, not a project.
What does leaving cost? Not exporting the data. Rebuilding every workflow, integration and habit that grew around it.

If a thing is a commodity, cheap to leave and invisible to customers, buy it today and stop discussing it. If it is the reason somebody picks you, build it properly and own it. Almost everything is the first kind.

This rule costs us work, and we apply it anyway

We turn down work that amounts to rebuilding something a client could rent. That is not generosity. An engineering budget spent on an internal CRM is a budget not spent on the thing that wins the next customer, and a client who runs out of money reconstructing commodity software does not come back for the project that mattered.

If you are weighing one of these, tell us what you are building and you will get an honest read on which side of the line it falls, including the times the answer is to buy it and not call us.

Originally published on the Lotus Tech Labs blog.

Your Next.js build should not need your database

Lotus Tech Labs — Fri, 02 Oct 2026 20:43:37 +0000

If a page reads from your database, render it on demand, not during the build. Prerendering it means your build container needs a route to Postgres, and on self-hosted infrastructure that route is the most host-specific thing you own. We learned this by paying for it.

What we were doing

This site runs Next.js with Payload CMS in-process, on Postgres, in Docker, on a single VPS. Six service pages moved into the CMS. They were dynamic segments with a generateStaticParams that queried Payload for every slug, so all six were prerendered into HTML at build time. That is the configuration every tutorial shows you, and on Vercel it works, because the build runs inside the same network as the managed database.

Ours does not. The build runs in a Docker build container, and a build container does not join the overlay network the services talk over. So the hostname the application resolves at runtime does not resolve at build time, and the build fails with a DNS error rather than anything that mentions networking.

What did not work

The obvious fix is to make the database reachable from the build: publish Postgres on the host and point the build at the Docker bridge gateway. We did that. It took five deploys to find the address.

Every answer online says the gateway is 172.17.0.1. On this box, inside the builder, it is not. We stopped guessing and made the build print its own default route:

RUN ip route | awk '/default/ {print "gateway is", $3}'

The only reliable way to learn a build container’s gateway is to ask it.

It answered 172.16.0.1 - specific to this host’s builder, not a Docker default, and not something any amount of reading would have told us.

That got the build passing, and left two bills. The database had to be published to the host to make it reachable at all, reversing a decision whose code comment read "publishing 5432 on a public IP is how Postgres instances end up in ransom notes". And the build now depended on one machine’s network layout, so rebuilding on EC2 would mean rediscovering that address, with a failed build as the only clue.

The documented workaround was worse

Payload documents a build mode for exactly this situation, next build --experimental-build-mode compile, which skips the data-fetching phase. It also stops inlining NEXT_PUBLIC_* environment variables.

On this site one of those values decides whether the response carries X-Robots-Tag: noindex. With it absent, a production build serves a correct-looking site that quietly tells every crawler to go away. The failure is invisible until organic traffic disappears weeks later.

A workaround that trades a loud build failure for a silent production one is not a workaround.

What we do instead

The dynamic segment stays, and its generateStaticParams returns an empty list. Deliberately - not as a fallback.

// app/(frontend)/services/[slug]/page.tsx

// Empty on purpose. Returning real slugs would query Payload, which would open a
// Postgres connection during `next build` and tie the build to one host's network.
// Unknown slugs still 404, because `dynamicParams` stays at its default.
export async function generateStaticParams() {
  return [];
}

Nothing is prerendered. The first request for a real slug renders the page in about 200ms and Next caches it; every request after that is a cache hit. When an editor publishes a change, the collection’s afterChange hook calls revalidatePath and the page updates without a deploy.

Postgres goes back to publishing nothing. The build secrets and the gateway detection are deleted. Nothing host-specific remains: moving to another server means restoring the database and deploying the containers.

Two things that look like fixes and are not

`export const revalidate` does not keep the build away from the database

Setting a revalidation period on a page does not stop Next prerendering it. It still renders the initial payload at build time and then refreshes on a timer afterwards. If that render reads your database, your build reads your database. The route has to be dynamic, not merely revalidating.

A page with no route parameters has no `generateStaticParams` to empty

We hit this the moment we added a blog index. There is no [slug] on /blog, so there is nothing to return an empty list from, and Next prerendered it:

Error occurred prerendering page "/blog".
cannot connect to Postgres: getaddrinfo ENOTFOUND base

The fix for a parameter-less page is export const dynamic = 'force-dynamic'. Same for anything Next evaluates at build: our sitemap and RSS feed are route handlers marked dynamic with their own cache headers, rather than the typed metadata files, precisely because they list posts from the CMS.

What it costs, stated plainly

This is a trade, not a free win, and the limits are worth naming because they decide whether it suits you:

The first request after a deploy is slower. About 200ms here, then cached. Fine for content pages; measure it before doing this to something latency-sensitive.
A database outage with a cold cache breaks those pages. Prerendered HTML would have survived it. We accept that: the pages that matter most are fully static and unaffected, and a health endpoint reports the database so the outage is visible rather than inferred.
Pages that are no longer files in the build output drop out of any CI check that inspects those files. Ours asserted one social-card image per page by reading the built HTML. That check had to be rewritten.
If you are on a managed database with a hostname reachable from anywhere, you can have both. We looked at that and chose not to add a monthly bill and an external dependency to a site this size.

We also decided against a fallback: if Postgres is unreachable the page fails rather than serving the copy committed in the repository. Visibly broken beats silently stale, because stale wording is the kind of thing nobody notices for a month.

The rule we kept

If it renders from a database, it renders on demand. Written down, with the reasoning, as an architecture decision record, because the next person to see an empty generateStaticParams will read it as an oversight and "fix" it. That one line is worth more than the fix itself: the build stopped being the thing that knows where our database lives, and that is what makes the stack portable.

If you hit the same wall, the short version is: do not teach your build how to reach your database. Teach your pages to render later. And if you are working through this on your own stack, tell us what broke - the failure modes above cost us real deploys, and the list is almost certainly not complete.