Building Systems: What I Learned 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 and experimenting with internal tools for EA and operations workflows. 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 single workspace that matched an EA's mental model felt straightforward. So far I've built the Travel, Visitor Log, and meeting notes modules for ExecOS — still a personal prototype, not something deployed at a company yet.

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 or API update.

If you're picking a model, match it to the task — writing and research, coding, or running things locally. The best choice depends on your workflow, not the hype cycle.

I also realized that chasing the new thing was procrastination. A simple workflow on a model you already understand — Claude, Gemini, or GPT — that is fully built and deployed today beats a half-baked prototype on whatever launched last Tuesday.

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.