Fewer Parts - Sunday Builder's Mindset
A jellyfish has no brain.
It’s been here 500 million years.
Sponges are simpler still. Six hundred million years. Horseshoe crabs have held the same body plan for 450 million. The nautilus, roughly 500 million.
Simple body plans outlast complex ones. Each organ is one more part that can fail. Fewer parts means fewer breaks. Fewer breaks means better odds across deep time.
I keep thinking about this alongside the thing I built last month.
It’s a daily news site. An AI prompt curates the stories, writes a single data file, and a static HTML page renders it. Git commit. Cloudflare picks it up with R2. It’s live. No CMS. No database. No authentication layer. No build pipeline. No deploy button.
It ships every single day.
The enterprise version of this would be a React dashboard with a PostgreSQL backend, an API gateway, a headless CMS, three environments, a staging server, and a team of four maintaining it. It would go down once a month. Someone files a ticket. Someone else triages the ticket. A third person fixes the deployment config. The dashboard comes back up. The cycle repeats.
My site doesn’t go down because there’s almost nothing there to break (except, sometimes, the AI part).
The instinct when you start building is to add.
Add a login page. Add user roles. Add an admin panel. Add analytics. Add a database migration strategy. Add error monitoring. Add a notification system. Add, add, add.
Every feature is a future maintenance bill. Every abstraction layer is a joint that can inflame.
You know this from clinical medicine. The patient on two medications does better than the patient on twelve. Not because the twelve are wrong — each one was added for a reason. But the interaction surface grows exponentially. The fragility compounds.
Polypharmacy kills. Polyfeature kills too.
The Stoics had a version of this.
Seneca kept saying it: it is not that we have a short time to live, but that we waste a great deal of it. Strip away what doesn’t serve. What remains is enough.
East of Eden put it differently. A character wracked with guilt over not being perfect enough is told by the family servant: “Now that you know you don’t have to be perfect, you can be good.”
Good is one prompt, one HTML file, and a git push that ships every morning.
Perfect is a full-stack application with sixteen dependencies that you’ll abandon in three months because the maintenance cost exceeded your clinical schedule.
Your edge as a clinician-builder is not that you can build complex things.
It’s that you know what to leave out.
You’ve spent years learning which labs matter and which ones are noise. Which exam findings change management and which ones go in the note but not in your head. Which medications to start and — harder — which ones to stop.
That subtraction skill is rare in software. Engineers and claude code usually add. To abstract. To generalize. To build for scale before there’s a single user.
You’re trained to do the opposite. Find the signal. Cut the noise. Treat the patient in front of you, not the theoretical one.
A jellyfish hunts with muscle and nerve. Nothing else.
The work gets done with fewer parts.
Build like that.
What are you building this week? Reply and tell me — I read every one.
— Kevin