The hardest part of building as an indie maker isn’t can I build it?
It’s I can build it… so why shouldn’t I?
This post is a decision log from the early days of uipad—an offline-first AI event planning assistant that helps organizers design a great in-person experience and walk into the room with a host script and printable cue cards in their pocket.
It’s not a tutorial. It’s the moment I realized that “more features” was quietly becoming “less product.”
1) My original plan: a tool that could plan everything
If you’ve ever built a product from scratch, you know the temptation:
- Add one more feature so it feels “complete”
- Support one more scenario so the market looks bigger
- Copy the playbook of existing platforms so people “get it”
That was me at the start.
My mental model of uipad looked like a typical event SaaS:
- Full multi-day agendas
- Participant-facing interactions (polls, live Q&A, real-time results)
- Dashboards, stats, “engagement”
- The whole “platform” vibe
It sounded reasonable. It also sounded like a product I could pitch in one sentence.
And that’s exactly why it was dangerous.
2) The moment it started breaking: complexity grew faster than value
As soon as I tried to design the experience, something felt off:
- Every new feature introduced a new state to manage
- Every new scenario stretched the UX and made the flow harder to explain
- The AI started “helping” in ways that weren’t consistent—because I wasn’t giving it a tight box
- Worst of all: I struggled to describe what the product was without listing features
That’s the classic shape of feature creep: “just one more feature” snowballs into a bloated scope that dilutes the core value proposition. Product scope is literally your boundary—what you will build, and what you won’t—without it, you’re building in the dark. 1
I wasn’t failing at execution.
I was failing at definition.
3) The turning point: I wrote a Not‑To‑Do list before writing more code
I stopped asking:
“What else should I add?”
And asked a more useful question:
“If I keep going like this, where does this product die?”
Then I wrote a Not‑To‑Do list. Not as a manifesto—more like guardrails.
- No participant-facing live interaction system
- No QR-code polling
- No real-time charts and dashboards
- No full multi-day agenda builder (at least not now)
- No features that pull people back into their phones during an in-person event
This wasn’t me “cutting features.”
It was me choosing what uipad would stand for.
And something surprising happened: the product instantly became easier to design.
4) The reframe: from feature-driven to boundary-driven
Once those “No’s” were explicit, uipad stopped being “an event management platform” and started becoming something sharper:
uipad is a planning pad for offline events.
It helps organizers design the flow, write what to say, and prepare materials they can actually use in the room.
That shift did three things:
It clarified the job-to-be-done
Not “manage an event.”
But “help me run this event without awkwardness and chaos.”It tamed the AI
When your product is “everything,” AI outputs can go everywhere.
When your product is “this specific outcome,” AI gets predictable.It made the UX simpler
Instead of building an endless editor, I could build guided blocks: opening → warm-up → peak → closing.
That’s the difference between shipping features and shipping a product.
5) What uipad became: an offline-first AI event planning assistant
This is the part that looks counterintuitive in a world full of “interactive” event tech:
uipad is intentionally offline-first.
It focuses on two things only:
A) Planning (designing the experience)
- A structured flow that won’t fall apart in real life
- Activity blocks that are realistic for in-person attention spans
- Copy that feels like a human wrote it (and is safe)
B) Organizing (helping the host do the job)
- Host scripts
- Printable cue cards (A6/A5)
- Large-screen “display assets” (like photo timeline prompts)
- A participant-facing info page (not an interaction page)
That’s it.
No “everyone scan and vote.”
No dependency on Wi‑Fi.
No forcing participants into another screen.
In other words: uipad is the backstage operator, not the onstage platform.
6) MVP isn’t “minimum features”—it’s “maximum clarity”
A lot of people talk about MVP as “the smallest set of features.”
But that framing is how you end up shipping a messy V1 that doesn’t actually solve a problem.
A better definition is: MVP exists for learning—getting something into real hands, learning, and iterating. It’s not a synonym for “V1 release.” 2
For uipad, the MVP question became:
“What is the smallest version that helps someone run an in-person event with confidence?”
Not:
“What is the smallest platform that looks like an event platform?”
That’s why the Not‑To‑Do list mattered more than any roadmap.
7) A practical rule I now use as an indie maker
When I’m tempted to add a new feature, I run a simple filter:
Does this strengthen the core promise—or does it create a second product?
For uipad, the core promise is:
- Offline-first
- Host-ready
- Planning + organizing support
- Materials you can use in the room
If a feature pulls me toward “live interaction platform,” it’s not a feature request.
It’s a different product.
And as an indie maker, the scarcest resource isn’t time or code—it’s your ability to carry complexity without drowning in it.
Closing: Saying “no” is not limitation—it’s leverage
It’s funny: the moment I started saying no with intention, I felt more confident about shipping.
Because the product stopped being a wish list and started being a tool with a point of view.
uipad has “pad” in the name for a reason.
It’s not a platform.
It’s a planning pad—simple enough to be used, strong enough to carry a real event.
If you’re building your own product, try writing your Not‑To‑Do list before you write another feature.
You might find the product hiding inside the boundaries.