Build · Proof

I don't just write about building.

Everyone says they're a builder. Most people mean a side project that never shipped. Here's what I've actually built — described in words, not screenshots, because what it taught me matters more than what it looks like.

A few years ago "building" was something I read about. Now, alongside a full-time BA job, I build — and I help other founders build their own platforms with AI too — different problem each time, same instinct: find the real problem, ship something people actually use, learn, repeat. No names, no logos, no city, no user counts, no revenue — not because there's something to hide, but because the point of this page was never the product. It's the work, and what it taught a BA about building for real.

What I've built

Three things, in words.

A two-sided booking platform

A marketplace I've helped build on the side: people search for a class or a session, book it, and pay for it — and the person running that session gets a dashboard to manage bookings, cancellations and payouts. No name here, no screenshot, no numbers on hosts or bookings — just what it is and what it taught me.

What it taught me: Payment flows don't forgive vague acceptance criteria. "Refund if it fails" isn't a requirement until you've written out every branch: failed payment, duplicate charge, host cancellation, no-show. I write tighter user stories now because I've had to debug the ones I wrote badly.

Internal ops tooling

Smaller tools nobody outside a small team will ever see — a dashboard here, an automation script there, each one solving one specific problem faster than a spreadsheet would have.

What it taught me: The best internal tool is the boring one nobody has to be trained on. I stopped trying to build something impressive and started building something a tired person could use correctly at 11pm.

The systems behind this newsletter

The subscribe form, the welcome email, the Saturday send — I built and run that too. It's the smallest of the three and the one people never think to ask about, which is exactly why it's here.

What it taught me: Nobody notices infrastructure that works. That's the whole job description, whether it's a newsletter pipeline or a production system a client depends on.

Takeaway

What building teaches the BA in me.

Acceptance criteria you'd accept from a client, you won't accept from yourself — until you're the one debugging the missing edge case at midnight.
Consent and security aren't checkboxes on a requirements doc; they're the first thing a real user notices the moment something goes wrong.
A dashboard is a requirement document that has to be right, because nobody's going to sit through a demo to tell you it's wrong.
Shipping something small and real teaches you more in a weekend than a course teaches you in a month.

I write more of this as it happens on the Build pillar — Build Notes and AI Receipts, real prompts and real outputs, still with no names attached.

Want the BA + AI angle every Saturday?

Subscribe for the newsletter, or book a 1:1 if you want to talk through your own build.

Enjoying the content?

Follow Dibya on LinkedIn, Instagram, and X for daily BA × AI insights and behind-the-scenes builds.