DEV Community

Cover image for How I Ship Features 10x Faster Than Most Developers (And Why Speed Is My Only Competitive Advantage)
Angelo Asante
Angelo Asante

Posted on

How I Ship Features 10x Faster Than Most Developers (And Why Speed Is My Only Competitive Advantage)

The systems, tools, and mindset that let a cleaner building between shifts outpace VC-backed startups.
Last Sunday night, I was bored.
So I built and launched a complete anonymous messaging app in five hours.
Full-stack web app. iOS app. Database. Real-time messaging. App Store submission.
All of it. Live. In one evening.
People asked me: "How?"
This is how.
The Unfair Advantage of Having No Time
I work as a cleaner. Four days a week. 2 PM to midnight. Forty hours total.
Most developers have forty-hour work weeks where they code for maybe twenty hours and spend twenty hours in meetings, on Slack, reviewing PRs, or just context-switching.
I have two thirty minute breaks per shift where I eat and code.
That's one hour of coding time during work days.
After my shift, I get home at 1 AM. I code until 6 AM. That's five hours.
Total: six hours per work day.
On my four days off, I code for twelve to fourteen hours straight.
So per week: six hours times four work days plus thirteen hours times four days off equals seventy six hours of actual coding time.
That's almost double what most full-time developers actually code.
But here's the thing: I don't have seventy six hours. I have one hundred twenty discrete coding sessions (two breaks per day times four days, plus all day sessions on days off).
Each session, I have to:

  • * Remember what I was doing
  • * Get back into flow
  • * Make progress
  • * Document for next session
  • * Context switch back to cleaning (or sleep) This should be impossible. Starting and stopping constantly should destroy productivity. Instead, it forced me to develop systems that make me faster than people who code uninterrupted.

System 1: Ruthless Modularity
When you only have thirty minutes, you can't build big features.
You have to build small, complete pieces.
So I write code in modules that can be finished in one session:
Instead of: "Build user authentication system" (four hours)
I do:

  • Session 1: Database schema for users (thirty minutes)
  • Session 2: Sign-up API endpoint (thirty minutes)
  • Session 3: Login API endpoint (thirty minutes)
  • Session 4: Auth middleware (thirty minutes)
  • Session 5: Frontend signup form (thirty minutes)
  • Session 6: Frontend login form (thirty minutes) Each piece works independently. Each piece is tested. Each piece is committed to git. If I get called away mid session, I haven't lost progress. Most developers write monolithic features. If they get interrupted, they lose context and have to start over. I write atomic features. Every thirty minutes, something ships.

System 2: Document Everything Immediately
At the end of every session, I write a commit message that my future self will understand.
Bad commit message: "fixed bug"

Good commit message: "Fixed date parser to handle 'tomorrow' and 'next Friday' inputs. Added test cases for relative dates. Next: Add support for 'in 3 days' format."
I also keep a TODO file that's updated every session:

CURRENT STATUS (Dec 14, 11:30 PM):
✅ User auth working
✅ Database schema complete
⚠️ Payment integration 80% done - webhook handler needs testing
⬜ Email notifications not started

NEXT SESSION:

  1. Test webhook handler with Stripe CLI (20 mins)
  2. Add error handling for failed payments (10 mins)

BLOCKERS:
- Need to fund payment processor test account (waiting for paycheck)
This takes three minutes at the end of each session.
It saves thirty minutes at the start of the next session.
Three minutes to save thirty. That's a 10x return.
Most developers don't document mid work. They rely on memory. Memory fails when you're context switching between mopping floors and writing TypeScript.

System 3: Tools That Multiply Effectiveness
I don't have time to fight with tools.
Every tool I use must:

  • Work immediately (no complex setup)
  • Have great documentation (no guessing)
  • Be actively maintained (no abandoned projects)
  • Deploy in seconds (no waiting)

My stack:
Frontend: Next.js (batteries included, great docs, Vercel deployment)
Database: Supabase (PostgreSQL managed, real-time built in, generous free tier)
Payments: Stripe + Paystack (both have excellent SDKs)
Auth: Supabase Auth (no rolling my own, no security headaches)
Hosting: Vercel (git push equals deploy, zero config)
Mobile: Expo (React Native without the pain, cloud builds)
APIs: Whatever has the best docs (I'll pay more for good documentation)
Notice what's missing: no Docker, no Kubernetes, no microservices, no GraphQL, no blockchain, no whatever's trendy this month.
Boring technology. Battle tested. Well documented.
This is intentional.
Shiny new tech costs time. Learning curves. Bug fixing. Limited Stack Overflow answers.
I can't afford that.
I use proven tools and move fast.

System 4: Code for Future Me
When I'm writing code at 3 AM after ten hours of cleaning, my brain is not sharp.
So I write code that 3 AM me can understand.
Rules:

  • Variable names are descriptive, not clever
  • Functions do one thing (no giant god functions)
  • Comments explain why, not what
  • Every edge case has a test
  • No "I'll refactor this later" (later never comes)
**Example of bad code (clever):
const p = await db.q('usr').w({id: uid}).s();
Example of good code (obvious):
const user = await database
  .query('users')
  .where({ id: userId })
  .single();**
Enter fullscreen mode Exit fullscreen mode

The second version is longer. But I understand it at 3 AM. I understand it after two weeks away from the codebase. I understand it when I'm half asleep on a work break.
Clarity beats cleverness every time.

System 5: Ship Before Perfect
I have a rule: If it works, ship it.
Not "if it's polished." Not "if it's optimized." Not "if it handles every edge case."
If the core functionality works, it goes live.
Then I iterate based on real usage.
Example:
My flight booking platform launched without:

  • User avatars
  • Social sharing
  • Reviews/ratings
  • Advanced filters
  • Price alerts
  • Saved searches Did users care? No. They wanted:
  • Search for flights
  • Book flights
  • Pay with mobile money That's what I built first. Everything else can wait. Most developers gold-plate. They add features nobody asked for. They optimize code nobody's running. They design for scale they don't have. I ship fast, learn fast, iterate fast. Version one doesn't need to be complete. It needs to exist.

System 6: Constraints as Features
I can't build everything. So I build the minimum.
But I frame it as intentional:
Constraint: I can't build complex form based search (too many fields, too much UI work)
Feature: "AI powered natural language search just tell us where you want to go"
Suddenly my limitation is a selling point.
Constraint: I can't afford 24/7 customer support
Feature: "WhatsApp support during UK business hours talk to the founder directly"
Now my constraint is a differentiator.
Constraint: I can't build native Android app yet (need to learn Kotlin or wait for Expo)
Feature: "iOS first launch with Android coming soon join waitlist for early Android access"
The limitation creates urgency and exclusivity.
I'm not hiding constraints. I'm reframing them as intentional product decisions.

System 7: Parallel Progress
When I'm blocked on one task, I switch to another.
Example from last week:

  • 6 PM: Start building payment integration
  • 6:20 PM: Stuck on webhook signature verification, docs unclear
  • 6:25 PM: Switch to building email templates (completely different task)
  • 7:00 PM: Email templates done, return to webhooks with fresh eyes
  • 7:10 PM: Figure out the issue, webhook working If I'd kept banging my head against webhooks, I'd have wasted forty minutes. Instead, I made progress on two fronts. I always have three tasks in progress:
  • Main task (what I'm focused on)
  • Backup task (if I get stuck on main)
  • Brain dead task (for when I'm exhausted) This way, I'm always moving forward.

System 8: Learning Just Enough
I don't read entire documentation. I don't take full courses. I don't watch hour long YouTube tutorials.
I learn exactly what I need, exactly when I need it.
Example:
I needed to integrate real time messaging for Ask Me Anon.
I didn't:

  • Read all of Supabase's real time docs
  • Watch tutorials on WebSockets
  • Learn about pub/sub architectures I just:
  • Googled "supabase realtime example"
  • Copied working code
  • Modified it for my use case
  • Tested it
  • Shipped it Total time: twenty minutes. If I'd "learned properly," it would have taken three hours. The difference is: I can always go deeper later. But I need to ship now. Learn on demand. Ship fast. Deepen knowledge when you have time.

System 9: No Meetings, No Distractions
I work alone. No team. No stakeholders. No stand ups. No retrospectives. No Slack.
Just me and the code.
This is a massive advantage.
Every meeting is an hour of coding I don't do. Every Slack conversation is broken focus.
I can't afford either.
So I don't have them.
When I need help, I:

  • Read documentation
  • Search Stack Overflow
  • Ask ChatGPT/Claude
  • Post on Twitter (get answers in minutes) All asynchronous. All on my schedule. The loneliness can be hard. But the productivity is unmatched.

System 10: Build in Public
I tweet my progress every few days.
Not for marketing. For accountability.
When I say "shipping X by Friday," I have to ship by Friday. My followers will notice if I don't.
External pressure keeps me honest.
It also:

  • Builds an audience before launch
  • Gets early feedback
  • Creates accountability buddies
  • Documents the journey All upside, zero cost.

The Actual Workflow (Hour by Hour)

Let me show you what a typical work day looks like:

2:00 PM: Leave for work with MacBook in backpack

2:15 PM - 5:00 PM: Clean offices, empty bins, mop floors

5:00 PM - 5:30 PM: First break

  • Grab food from backpack
  • Eat while reading code from last session
  • Remember context
  • Open laptop
  • Fix one small bug or build one small feature
  • Commit and push
  • Document next steps
  • Close laptop

5:30 PM - 8:00 PM: More cleaning

8:00 PM - 8:30 PM: Second break

  • Same routine
  • Fix/build
  • Commit
  • Document

8:30 PM - 12:00 AM: Finish work

12:30 AM: Get home

1:00 AM - 6:00 AM: Deep work

  • No interruptions
  • This is when major features get built
  • Usually 3-4 complete features per night
  • Commit after each
  • Push everything before sleep

6:00 AM: Sleep

1:00 PM: Wake up, check notifications, plan next session
That's how I get more done in breaks and late nights than most developers do in full work days.

The Results
Using these systems, I've built in the last nine months:

Diaspora AI (flight booking platform):

  • * Full stack Next.js application
  • * AI-powered flight search
  • * Dual payment processing (two different APIs)
  • * WhatsApp booking bot
  • * Admin dashboard with analytics
  • * Visa requirement guides for seventeen countries
  • * Email notifications
  • * Mobile responsive UI
  • * Profit tracking and financial systems
  • * Complete documentation

Ask Me Anon (anonymous messaging):

  • * Full stack Next.js web app
  • * React Native iOS app
  • * Real time messaging
  • * User authentication
  • * App Store submission
  • * All in five hours

Nelson Data Services (for a friend):

  • * Data bundle purchasing platform
  • * Mobile money integration
  • * Automated fulfillment
  • * Built in one week

flyabroadpartners.co.uk (for my dad):

  • * Travel agency website
  • * Custom design
  • * Working contact form
  • * SEO optimization
  • * Built in two weeks

That's four production applications in nine months.
While working forty hours a week as a cleaner.
Most developers ship one project per year.
I ship one per quarter.
Not because I'm smarter. Because I've systematized speed.

Why Speed Matters More Than Anything

In startups, speed is everything.
The faster you ship, the faster you learn. The faster you learn, the faster you iterate. The faster you iterate, the faster you find product market fit.
I can't compete with VC backed startups on money. They have millions. I have my cleaning salary.
I can't compete on team size. They have engineers, designers, product managers. I have me.
But I can compete on speed.
They need board approval to change strategy. I can pivot overnight.
They need sprints and story points. I just build.
They need stakeholder buy in. I decide and ship.
Speed is my moat.

The Tradeoffs

This approach isn't perfect.

What I sacrifice:

  • Code quality: My code works but isn't always elegant
  • Testing: I test critical paths but not everything
  • Documentation: Comments and commit messages but no formal docs
  • Scale: Built for current needs, not future millions of users
  • Team collaboration: Everything is optimized for solo work

What I gain:

  • Shipping speed: 10x faster than traditional development
  • Learning speed: I hit problems fast and solve them fast
  • Market validation: Real users, real feedback, real data
  • Competitive advantage: I move before competitors react
  • Focus: No distractions, just building For a solo founder with no funding trying to compete against billion dollar companies? I'll take that trade every time.

For Developers Who Want to Move Faster

You don't need to work cleaning job hours to use these systems.
You just need to:

Modularize everything.
Build features you can finish in one sitting. No half done work.

Document obsessively.
Future you will thank you. Comments, commit messages, TODO files.

Choose "boring" technology.
Proven tools with great docs. No shiny object syndrome.

Ship before perfect.
Working beats polished. Iterate based on usage

Build in public.
Accountability drives results. Tweet your progress.

Remove distractions.
Close Slack. Skip meetings if possible. Focus.
Learn on demand. Don't study everything. Learn what you need when you need it.

Have backup tasks.
Never be blocked. Always have something productive to do.
These systems work whether you code two hours a day or eight.
The principles scale.

The Real Secret

Want to know the actual secret to shipping fast?
It's not tools. It's not systems. It's not workflows.
It's caring deeply about the problem you're solving.
I don't ship fast because I'm disciplined.
I ship fast because I'm desperate.
Desperate to quit cleaning toilets. Desperate to prove I can build. Desperate to create something that matters.
That desperation focuses the mind.
I don't have time to waste on features nobody wants. I don't have energy to over engineer solutions. I don't have budget to make mistakes.
So I don't.
I build what's needed. I ship what works. I iterate based on reality.
Not because I'm smart.
Because I have no choice.

Closing Thought

The most common question I get is: "How do you find time to code while working full time?"
Wrong question.
The right question is: "How do I make every minute of coding time count?"
Because you don't need more time.
You need better systems.
You need clearer priorities.
You need to stop goldplating and start shipping.
The developers who ship fastest aren't the ones with the most time.
They're the ones who use their time best.
I code in thirty minute bursts between cleaning toilets.
If I can ship production applications doing that, you can ship with whatever time you have.
Stop waiting for perfect circumstances.
Build the systems. Ship the code. Move fast.
The world doesn't need more perfect software.
It needs more shipped software.

Current projects:

  • Diaspora AI (flight booking) - launching Jan 1, 2025, early access live at diasporaai.dev try it out and tell me what you think

  • Ask Me Anon (anonymous messaging) - live now at askmeanon.com try it out and tell me what you think

Follow the journey:

Travis Moore (Angelo Asante)

Self Taught Developer

Professional Cleaner & Speed Demon

Plymouth, UK

Top comments (0)