Seems easy to say. Keep it simple.
If you’re not in production yet, don’t pretend you are.
No one needs a Kubernetes cluster just so you can click through three screens and say
“look, it scales” 😅
Design your APIs as learning tools.
You will revisit them.
You will rewrite parts of them.
That’s not failure. That’s the job.
Self document everything.
If your API needs a separate explainer document just to understand what it does, you’ve already made life harder than it needs to be.
And most importantly, control the narrative 🎯
What you build should support the story you’re telling.
A good demo is not just working software.
It’s a clear journey from problem to value.
It’s also completely fine to say
“this part is coming soon”
In fact, it’s usually better than overbuilding something nobody actually needs.
It’s simple lessons, right?
But – the number of times I’ve seen teams turn a demo into an accidental architecture project is… impressive 😄
I, ahem, cough, may have done the same thing myself. Possibly. Ahem.
Next time, though, tell yourself this :-
- Build to learn.
- Demo to convince.