Building Systems: What I Learned in the hard way

If you scroll through LinkedIn or Twitter, it feels like everyone has suddenly become an "AI expert" overnight.

Honestly, I'm not one. I started building things in April 2026 — right when vibe coding tools like Lovable and Cursor started blowing up. I've been building tools that founders, EAs, and project managers actually use daily. Made plenty of mistakes, over-engineered simple stuff, wrote a hundred bad prompts before getting one right. But that's how I learned what actually works.

Here's what I've picked up so far.

1. Couldn't automate what wasn't understood

When I first set out to build ExecOS (a dashboard to help founders and EAs manage travel and visitor logs), I didn't have to guess what features to build. I had already lived the friction.

Having worked as an EA to the Director in the education industry and as a Secretary to the CDO on a massive airport project, I knew the daily grind by heart. I had spent years managing calendars that changed by the minute, tracking flights across emails, and logging expenses in spreadsheets.

Because I had lived the manual grind myself, building a cockpit system and a single source of truth that actually fit an EA's mental model was simple. By the way, till now i build Travel Module, Visitor Log Module including meeting notes module for ExecOS, that can save more than 10 hours a week.

You have to live the manual steps before you can write the code to automate them.

2. AI can't fix a broken process — it just executes it faster

When I first started building ExecOS, I thought if I just layered AI on top of the modules, the system would practically run itself. Travel log, visitor entries, meeting notes — I had all the data spread across emails and spreadsheets anyway. So I quickly added AI actions: auto-fill visitor details from past entries, summarize meeting notes into action items, suggest next scheduling slots.

First version was a mess. The visitor module was pulling default entries from people who had visited six months ago. The meeting notes summary was skipping the actual decisions and only listing the pleasantries at the end. The travel log was suggesting routes that didn't make sense for the itinerary.

That's when it hit me: AI is accelerant, not a mechanic. I had jumped straight to adding AI before I had actually mapped out how I managed these things manually — what went where, which fields mattered, what I ignored. You can't automate a process you haven't spelled out to yourself first. I went back, wrote down my actual workflow for each module, cleaned up the data structures, and rebuilt the AI layer against that. Within a day, the outputs went from garbage to usable.

Fix the workflow first. Then give it to the AI.

3. Dropping the politeness made my prompts work

When I started building ExecOS's Travel Module, I wrote the system prompt like I was instructing a real assistant. *"Please keep this short and friendly"* — seemed reasonable.

The AI nodded along and produced two paragraphs of corporate-sounding nothing. Every. Single. Time.

I must have rewritten that prompt twenty times, polishing the language, adding more adjectives, begging for better output. Nothing changed.

Then I stopped being nice. I wrote it like a rulebook: word count under 150, zero corporate jargon, always offer exactly three time slots. No "please," no "kindly," just straight instructions.

Feels rude to read even now. But the first time I ran that version? Output came out clean, sharp, actually useful. Turns out LLMs don't care about being asked nicely. They follow instructions.

4. The best systems still have humans in the driver's seat

For ExecOS, I initially dreamed of a fully autonomous travel manager — one that could book flights, approve expenses, and handle last-minute changes without any human input. I built it, demoed it, and panicked.

Turns out, no founder wants an AI silently cancelling their preferred flight class because it found a cheaper option. Keeping a human in the loop — reviewing, approving, overriding — is what makes the system usable.

The goal isn't to replace the decision-maker. It's to remove the busywork so they can focus on the decisions that actually matter.

5. I had to stop chasing the "shiny object"

It's easy to get distracted by tool-chasing. Every week there's a new model release like the global restoration of Anthropic's Claude Fable 5 and Mythos 5, GLM-5.2 open-weight coding model by Zhipu AI or a new API.

If you are deciding which model to use, decide on what task you are working on like Writing and research or Coding and building software, or Running models locally offline, the best model depends on your specific workflow.

I also realized that chasing the new hype was just a form of procrastination. A simple workflow running on Claude sonnet 5 or Claude Opus 4.8 or Haiku 4.5, or Gemini 3.5 Flash or OpenAI's Frontier GPT-5 Series that is fully built and deployed today is worth more than a half-baked prototype on the "newest" model.

So, choose a stack, finish the workflow, and let it run.

---

Where I'm going next

I'm still learning every single day. The tech is changing, but the core human problem remains the same: how do we get our time back from repetitive work?

If you're currently building operations tools, struggling with manual grinds, or trying to figure out how to automate your workflows, let's connect. I'd love to chat and hear what lessons you're learning on your own journey.