Home / Articles / Simplified, or outsourced? A reply to Nadzeya Stalbouskaya on removing servers and databases / Versions / v1.2.0
Simplified, or outsourced? A reply to Nadzeya Stalbouskaya on removing servers and databases: what changed in v1.2.0
From v1.1.0 (2026-10-25, b4bf7bb20) to v1.2.0 (2026-10-25, 9b4a89d1f), paragraph by paragraph.
0 paragraphs added, 0 removed, 3 changed in place, 31 unchanged. About 0 words added and 3 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names.
← v1.1.0 · all versions · v1.3.0 →
1 unchanged paragraph
Summary: Under my LinkedIn comment that I run with no databases, serverless services and no server-side code of my own, Nadzeya Stalbouskaya asked a good question: removing servers and databases does not necessarily remove complexity; sometimes it just moves it into external services, APIs and dependencies we do not fully control, trading operational overhead today for dependency and lock-in tomorrow. So how do you tell genuinely simplifying an architecture from outsourcing its complexity? My answer: sheNadzeya is right that there is risk, and it must be a conscious decision. The way to make it is to map it. On a Wardley map, moving a component from custom-built to commodity removes complexity only if what you move to really is a commodity. Replacing our own login with passkeys is that: a standard every major browser and platform supports, with a track record. Moving our data to object storage and static hosting is too. But moving to a young startup's service can look like a commodity on our map while, behind it, it is as messy as what we had, or worse. So you de-risk the move by choosing the commodity, and you can test which one you have by asking who would certify it, insure it, or sign a high SLA on it. Maturity and certifiability go together.
11 unchanged paragraphs, under In short {#in-short}, The question {#question}
SheNadzeya is right that there is risk. And I would argue that it has to be a very conscious decision. If you replace a server or a service of your own with a third-party component that is itself an explorer project, or even a villager one, then I agree: you have outsourced your complexity, and probably added some. The difference is the town planner services, the commodities. By design, they are very stable. They are effective, they have a track record, documentation and SLAs, and a level of maturity your own version will never have. Which is why you have to map it.
19 unchanged paragraphs, under Map it {#map}, Where our own products sit {#ours}, Who would certify it? {#certify}…
The LinkedIn thread, under Stephan Bitton's post, from a screenshot: my reply to him and Nadzeya Stalbouskaya's comment, quoted with her words as written; my voice memo of the same day. The FIDO Alliance, passkeys, read on 25 October 2026; CNBC, Google passkeys now default login option for Google accounts, 10 October 2023; pki.sgit.ai. Related: explorer coding, the attack surface you do not have, the no-server startup, ephemeral town planner services, who signs for this?, signed by the source. Written up and checked by this site's agent, newsroom.writer; the editorial responsibility is mine.