DEV Community

Cover image for Someone Already Built That — Good. Ship the Version Your City Needs
Chaminade Dondah ADJOLOU
Chaminade Dondah ADJOLOU

Posted on

Someone Already Built That — Good. Ship the Version Your City Needs

There is a sentence that kills more side projects than broken laptops:

"Someone already built that."

I hear it in Discord servers, in campus halls, and after GDG Lomé meetups when someone sketches an idea on a sticky note. A rideshare for campus. A WhatsApp-first inventory tool for a small shop. A Flutter app that shows exam schedules offline. Then the room goes quiet because Notion / Uber / Google Calendar / "that SaaS from San Francisco" exists.

Existence is not the same as fit.

This is a builder pep talk with a practical filter — how I decide what is worth shipping when the category already looks crowded.

Crowded categories still have empty chairs

Global tools optimize for global averages. Your neighbors do not live on averages.

In Lomé (and in a lot of places like it), "someone already built that" often means:

  • The polished product assumes always-on broadband
  • Pricing is in a currency or card network people struggle with
  • Onboarding wants a work email, not a phone number
  • Support is English-only at hours that ignore your timezone
  • The workflow ignores cash, agents, shared family devices, or intermittent power

You are not competing with the brand. You are competing with friction on the ground.

A better question than "is it original?"

Try this instead:

Who already suffers weekly, and what ugly workaround do they use today?

Ugly workarounds are product specs wearing camouflage:

  • Spreadsheets emailed as final_v7_REAL.xls
  • WhatsApp groups used as ticketing systems
  • Paper notebooks for stock counts
  • Screenshots of QR codes saved in gallery folders
  • "Call me when you're outside; the gate code changes"

If people already pay time, money, or dignity to a workaround, a focused tool can win even if a giant brand exists in the same noun category ("calendar", "delivery", "CRM").

The Boring Problem Scorecard

Boring Problem Scorecard with five meters: Frequency, Pain, Reach, Distribution, Build slice

Figure: score the idea before you open the editor.

Before I open VS Code, I score an idea 1–5 on each line:

  1. Frequency — Do they hit this pain weekly?
  2. Pain intensity — Is the workaround embarrassing or expensive?
  3. Reachability — Can I talk to 5 real users this month without a marketing budget?
  4. Distribution — Can I put it where they already are (WhatsApp link, Play Store, campus poster, meetup)?
  5. Build slice — Can I ship a useful v0 in two weekends?

If the total is under ~16, I park it. If frequency and reachability are both low, I walk away even if the idea sounds clever on Twitter.

Notice what is missing: "Is the tech stack exciting?" Excitement is a terrible primary filter when you want users.

Case sketch: not a unicorn, a wedge

Imagine "event check-in for local tech meetups."

Someone already built Eventbrite. Cool.

What a Lomé / campus / GDG-shaped wedge can still own:

  • Works when the venue Wi‑Fi dies (QR tokens cached on device)
  • Accepts cash + mark-as-paid by organizer
  • French + local language labels without enterprise pricing
  • Organizer phone is the admin console
  • Export to a simple CSV for sponsors, not a 40-page analytics suite

That product will never trend on Hacker News. It might become the default for ten communities. Ten communities is a real business and a real portfolio.

How to ship without waiting for permission

1) Pick one workflow, not a platform

Platforms are how ideas die in notebooks. Ship:

  • "Add stock in / stock out with a photo"
  • "Generate tomorrow's delivery list from yesterday's WhatsApp orders"
  • "Offline timetable + exam reminders"

Name the verb.

2) Steal the distribution channel users already trust

If your users live in WhatsApp, your first UI might be:

  • A link that opens a clean mobile web form
  • A bot that only does three commands
  • A Flutter app that shares results back into the chat

Meeting users halfway beats a beautiful deserted dashboard.

3) Charge something small early (or trade clearly)

Free forever trains people to ghost you. Options:

  • Small monthly fee
  • One-time setup for a shop
  • "Free for student clubs / paid for businesses"
  • Clear barter (you get case study rights)

Money is a feedback instrument. Even a tiny amount tells you if the pain is real.

4) Instrument learning, not vanity metrics

Track:

  • Weekly active organizers / shops — not page views
  • Time-to-first-success ("created first event in under 5 minutes?")
  • Support questions that repeat (those are your next features)

Ignore follower counts until the workflow is sticky.

What to tell yourself when the excuse returns

When your brain says "someone already built that," answer with:

  • For whom?
  • Under which constraints?
  • With which distribution?
  • At what price and support model?

If you cannot answer those, you do not actually know whether the chair is empty.

Career angle for beginners

Hiring managers and clients rarely need another clone of a tutorial CRUD app with no users. They pay attention when you say:

"I shipped a check-in tool used by three campus clubs. Here is what broke on offline night-one, and how we fixed it."

That story beats "I know React hooks" every time — and you can tell it honestly whether the app is React, Flutter, or a boring Node script behind a form.

Building local wedges also teaches product sense: scoping, support, and empathy. Those skills travel to any stack.

Takeaways

  1. "Someone already built that" describes a category, not your constraints.
  2. Hunt weekly workarounds — they are requirements documents.
  3. Score frequency, pain, reachability, distribution, and a two-weekend slice.
  4. Ship one verb, meet people on their channels, get real feedback (ideally paid).
  5. Portfolio stories about users under constraints beat tutorial clones.

If you are sitting on an idea you shelved because a big brand exists, comment with the category and the local constraint (offline, cash, language, device sharing). Let's pressure-test whether the chair is actually empty.

Top comments (0)