From freelancer to 7-figure-ARR productized service

Amin Memon, founder of Draftss

Amin Memon turned his solo freelance gigs into a two-person productized service shop called Draftss. Then, he grew that into a multi-seven-figure ARR business with a team of 70. And while he was at it, he scratched his own itch with an email infrastructure platform.

Here's Amin on how he did it. 👇

Surviving long enough to figure things out

I’m Amin, a bootstrapped founder. I’ve spent the last 8 years building internet businesses mostly in SaaS, design, and growth marketing.

Before becoming a full-time founder, I was heavily into design and conversion optimization. I used to redesign websites, improve landing pages, and study why certain products converted while others didn’t. Over time, that naturally evolved into building my own products instead of just working on other people’s products.

Today, I primarily focus on two companies:

  • Draftss — a subscription-based design, UI, video, marketing, and development service for startups, SaaS companies, and agencies. Companies can hire an entire creative + development team on a monthly subscription instead of hiring freelancers or building large in-house teams. We’ve grown it completely bootstrapped into a multi-7-figure business serving thousands of founders over the years.

  • Deliveryman.ai — a cold email infrastructure platform that helps users scale outbound email without buying and managing dozens of inboxes or handling deliverability operations manually. The product came from our own frustration with how complex cold email infrastructure had become.

Most of what we’ve built came from scratching our own itch. We never raised funding or had a huge launch moment. We learned everything through trial and error — and surviving long enough to figure things out.

Finding the problem while freelancing

While we were freelancing, my cofounder and I repeatedly saw the same problem. Early-stage companies needed consistent good design and development work, but hiring full-time teams was expensive, and managing freelancers was chaotic.

Simultaneously, we noticed startups didn't want "a designer." They wanted speed, reliability, and someone who could execute without endless back-and-forth.

That insight became Draftss.

We started very small. No funding, no audience, no network. In the early days, we did everything ourselves: design, support, sales, onboarding, and revisions. The productized subscription model was relatively new then, so we were figuring it out as we went.

Deliveryman.ai had a similar origin. We heavily used cold email internally and grew tired of the operational mess around deliverability: buying inboxes, warming them up, monitoring reputation, replacing burned domains, and constantly managing infrastructure. It felt like too much engineering work just to send emails.

Instead of accepting the workflow, we built internal systems to simplify it. We eventually realized other companies had the same problem, and released it as a product.

Building systems over products

The initial version was much simpler than people probably imagine.

For Draftss, we didn’t start by building some sophisticated platform or hiring a huge team. Initially, we just packaged our existing freelance/design work into something more predictable and scalable.

The biggest challenge wasn’t design or development; it was designing the system around the service.

We had to figure out:

  • How do we scope tasks without endless meetings?

  • How do we make turnaround times fast without compromising quality?

  • How do we handle unlimited requests sustainably?

  • How do we hire and train creatives consistently?

  • How do we make the experience feel productized instead of like a traditional agency?

We obsessed over workflows, async communication, onboarding, task management, and creating clear processes so clients moved fast without constant hand-holding.

In the early days, we manually handled almost everything ourselves. And we quickly learned that small operational inefficiencies become huge problems once subscriptions compound.

For Deliveryman.ai, the first versions were even scrappier. We weren’t trying to build a SaaS company. We just tried to reduce our operational pain. And then we turned our gains into a product.

Draftss homepage

A practical stack

We’ve always tried to keep the stack practical instead of chasing trends. Across our products, we mostly use:

  • Frontend: React, Next.js, Astro

  • Backend: Python + Django REST Framework (DRF)

  • Database: PostgreSQL, Redis

  • Infrastructure: AWS, Docker

  • Automation & internal tooling: A mix of custom scripts, APIs, and AI-assisted workflows

For Draftss specifically, the real “tech” is operational infrastructure like internal workflows, async systems, project management pipelines, QA processes, hiring/training systems, and automation for task handling. This allows us to scale a subscription service without it turning into complete chaos.

For Deliveryman.ai, the infrastructure is much heavier because email deliverability is extremely technical. We spend significant time on inbox infrastructure, reputation systems, warm-up logic, routing, monitoring, and automation for deliverability operations.

Over the years, I've seen a lot of early-stage founders over-optimizing architecture too early. For us, speed of iteration mattered far more than having the “perfect” stack. We focused more on solving customer problems quickly and evolving the tech as the business matured.

Community, cold email, and SEO

In the early days, community-driven marketing drove most of our growth. We actively launched and participated in places where founders already hung out, such as Reddit, Indie Hackers, Facebook Groups, startup communities, and niche SaaS spaces.

Instead of treating those platforms like advertising channels, we focused on sharing learnings, experiments, case studies, and genuinely useful content. That built trust over time and brought in our earliest customers organically.

Cold email and SEO also played a significant role, especially since we were bootstrapped and needed efficient acquisition.

Later, once we understood our positioning and conversion funnels better, we started experimenting more with paid ads. Ads worked much better once we knew what messaging resonated organically, because we then had years of customer feedback and positioning insights.

Efficiency over growth hacks

Both businesses use recurring subscription models. These models provided predictable early revenue and allowed us to grow sustainably without external funding.

For Draftss, customers pay a monthly subscription for access to an on-demand creative, marketing, and development team instead of hiring internally or managing multiple freelancers. Retention and word-of-mouth were the biggest drivers of revenue growth. Once startups integrated us into their workflow, many stayed for long periods and organically referred other founders.

For Deliveryman.ai, the model is also subscription-based, focusing on cold email infrastructure and deliverability operations. Since outbound is a core growth channel for many businesses, customers care deeply about reliability and scalability. This naturally creates recurring demand.

We grew revenue by continuously improving positioning, onboarding, and operational efficiency rather than chasing aggressive growth hacks. Small improvements in conversion rates, retention, referrals, and customer experience compounded significantly over time.

The real challenges of bootstrapping

When bootstrapping, the hardest problems were rarely technical. The real challenge was managing energy, focus, and decision fatigue over long periods of time.

No external pressure forces momentum. No investors, no board meetings, and no launch deadlines exist except those you create. This sounds freeing... until you realize you must generate your own internal clarity and urgency for years.

We experienced phases of financial growth, but still felt stuck because operational complexity increased faster than revenue. More customers created more edge cases, more communication overhead, more hiring challenges, and more internal coordination problems.

That's when I realized scaling wasn't about adding more people; it was about reducing chaos. And it changed how we built everything afterward.

We obsessed over removing friction: Fewer meetings, clearer processes, better async communication, better hiring filters, better documentation, better onboarding, and better internal tooling.

I also underestimated the emotional difficulty of long-term consistency.

The internet features massive “startup moments” like launches, revenue screenshots, funding announcements, and viral growth. But most real businesses are built during long periods when nothing looks externally exciting.

What he would do differently

If I had to start over, I’d optimize earlier for leverage instead of activity.

Earlier, I confused busyness with progress. Now, I think in terms of what scales, what compounds, and what reduces future effort.

I would also spend more time talking to users before building solutions. Some of our best decisions came directly from observing frustrating workflows instead of brainstorming startup ideas in isolation.

Ironically, the biggest breakthroughs usually came when we stopped trying to look like a startup and started behaving more like problem solvers.

Start smaller and distribute earlier

Here's my advice:

  • Start much smaller than you think you need to. A lot of founders waste years waiting for the perfect idea, perfect product, perfect timing, or perfect stack. Most successful businesses solve a simple but painful problem consistently well.

  • Focus on distribution earlier. A decent product with strong distribution usually beats a great product nobody knows exists. Learn how to communicate value, write clearly, understand positioning, and get your product in front of communities where your users already spend time.

  • Most importantly, stay in the game long enough. Most advantages in business compound quietly — like skills, reputation, audience, relationships, distribution, customer trust, and pattern recognition. People often quit before those compounding effects become visible.

You don’t need to be the smartest founder in the room. You just need to keep learning, experimenting, and improving longer than most people are willing to.

What's next?

Our biggest goal is to keep building durable internet businesses that can compound for decades — we aren't chasing short-term startup hype.

For Draftss, we want to continue evolving beyond “design subscriptions” into a more complete async creative and execution partner for modern internet companies.

For Deliveryman.ai, we focus on simplifying outbound infrastructure even further. Cold email is still unnecessarily technical for most businesses, and we see a huge opportunity to completely abstract away that complexity.

Personally, I also want to share more of what we’re learning publicly. For years, we mostly built quietly in the background. Now, I’m increasingly interested in documenting experiments, growth lessons, systems, failures, and operational insights for other founders building bootstrapped companies.

You can find me on X and LinkedIn. Or learn more about Draftss and Deliveryman.ai.

Indie Hackers Newsletter: Subscribe to get the latest stories, trends, and insights for indie hackers in your inbox 3x/week.

About the Author

Photo of James Fleischmann James Fleischmann

I've been writing with Indie Hackers for the better part of a decade. In that time, I've interviewed hundreds of startup founders about their wins, losses, and lessons. I'm also the cofounder of dbrief (automated expert interviews) and LoomFlows (customer feedback via Loom). I'm the creator of a newsletter called Ancient Beat (archaeo/anthro news). And I built and sold SaaS Watch.

Support This Post

34

Leave a Comment

  1. 1

    Scaling wasn't about adding more people, it was about reducing chaos" is the line that stands out most. I see this constantly with early-stage founders, they assume their growth problem is acquisition when it's actually that the product experience gets harder to understand as it gets more features. Curious how you approached onboarding differently for Draftss vs Deliveryman, given how different the two products are.

  2. 1

    "Amin's story is a masterclass in productizing before scaling — most freelancers skip straight to hiring without ever nailing down a repeatable process first. The jump from solo gigs to 70-person team is impressive, but I'm more curious about the early days: how did he price his first productized offer, and how did he get those first 10 clients to trust a one-person shop? That transition is where most people get stuck."

  3. 1

     great job, wishes u best of luck

  4. 1

    Selling RemoteJuniors — niche remote job board for juniors. 8 weeks old, 5.7K visitors, 500+ email subs, 1.9K Threads followers, all organic. $2,999 reserve on Flippa. Motivated seller needed. Dm for link

  5. 1

    Scaling wasn't about adding more people; it was about reducing chaos" is probably the most underrated insight in this entire post. Most bootstrapped founders hit a revenue milestone and immediately think headcount, when the actual problem is operational complexity growing faster than the systems designed to contain it.

    The point about busyness versus leverage is real and it takes longer than it should to internalize. Early on, activity feels like progress because you're moving constantly. The shift happens when you start asking whether the thing you're spending 3 hours on will matter in 6 months or whether it just feels urgent today.

    The origin of delivery . ai is a good example of the best kind of product discovery — you were already your own customer, the pain was real and recurring, and the build started as internal tooling before it became a product. That sequence almost always produces something more honest than brainstorming ideas in isolation.

    One thing I'd push on from your advice: distribution earlier is right, but I'd add that community participation specifically is undervalued compared to content or paid. You mentioned Reddit and Indie Hackers drove early growth — that kind of trust-building in existing communities is something most founders skip because it's slow and doesn't look like marketing. But it compounds in ways that ads don't.

    Eight years bootstrapped to multi-seven figures without funding is a genuinely rare outcome. The "survive long enough to figure it out" framing is honest in a way most founder stories aren't.

  6. 1

    I think a lot of founders underestimate reducing chaos. The product can be simple, the stack can be simple, but the messy part is usually the system around it: onboarding, communication, delivery, hiring, support, and all the small decisions that repeat every week. This is a good reminder that distribution matters earlier than most technical founders want to admit.

  7. 1

    nice post

  8. 1

    This is pure structural gold, Amin. Especially the line: 'Scaling wasn't about adding more people; it was about reducing chaos.'

    As a bootstrapped founder currently building an AI-mediated social project (Echo), I recently had to ruthlessly strip down my entire product thesis because of feature bloat, moving away from past experimental features to pivot entirely into a brutalist, text-heavy sandbox to nail the core vibe. I used to confuse busyness with progress, over-engineering the 'perfect' ecosystem before letting users stress-test the core subtext.

    Your insight on building systems over products is exactly the paradigm shift I needed to hear today while optimizing my launch flow. Distribution and staying in the game long enough is the real code.

    Definitely bookmarking Draftss and Deliveryman for when we start scaling our outbound and creative workflows. Thanks for laying out the blueprints so rawly.

  9. 1

    Good to read a story like this, thank you!

    when you've solved all the things that 90% of us might never solve, like creating a product based on an actual demand or problem that needs to be solved and afterwards operate its execution, growth strategy becomes the real bottleneck.
    You have my deepest respect for that path you're walking on!

    1. 1

      Totally agree. Once a product has real demand and a working execution system, growth becomes less about “more tactics” and more about knowing which channels can compound without adding chaos.

      For AI products especially, I think there’s another layer: growth and cost structure have to be designed together. A campaign that brings in users but creates unpredictable AI/API usage can look good on acquisition and bad on margins.

      The better systems track not just leads or conversions, but cost per useful workflow, cost per activated user, and which AI tasks are actually creating value versus just consuming budget.

    2. 1

      Try to solve one problem. Encouter a lot of problems on the way == Discover more ideas to solve :)

  10. 1

    the Deliveryman origin story of building internal tooling for cold email infrastructure and then realizing others had the same problem is interesting because it's a productization decision that most service businesses never make. you had operational gains, decided to package them, and got a second company out of it. curious how you knew when the internal tooling was far enough along to be worth productizing versus just useful internally. what was the signal that made you decide to release it rather than keep it as a competitive advantage

    1. 1

      Great question. I think the signal is usually when the internal tool stops being a private efficiency gain and starts solving a repeated pain with a clear external buyer.

      For AI/internal automation tools, I’d add one more test: can the workflow stay reliable and economically predictable when someone outside your own team uses it?

      A lot of internal tools work because the original team understands the edge cases. Productizing means packaging the workflow, defaults, cost controls, onboarding, and failure modes so another team can get the same value without your context.

    2. 1

      Yes, Since we have built the entire email layer from ground up. We are trying to figure out what other related projects we could launch along with it.

  11. 1

    This is really inspiring,
    Going from solo freelance to scaling Draftss into a multi-7-figure productized service business with 70 people is seriously impressive. Loved the focus on building systems and staying in the game long enough.

  12. 1

    "Scaling wasn't about adding more people. It was about reducing chaos."

    We're seeing something very similar in ad operations.

    A lot of teams assume growth problems are solved by hiring more people or adding more tools. But many bottlenecks come from manual workflows, handoffs, reporting, and operational complexity.

    The more customers you have, the more expensive small inefficiencies become. Great reminder that systems often scale better than heroics.

    1. 1

      This applies really well to ad ops. A lot of the pain is not “we need more tools,” but that reporting, handoffs, QA, campaign checks, and performance summaries become more expensive as the account count grows.

      AI can help here, but only if it reduces operational noise instead of adding another layer to manage. I’d think about routing the workflow by risk: lightweight automation for routine checks and summaries, stronger reasoning for anomaly detection or budget-impacting recommendations, and human review where spend or client trust is involved.

  13. 1

    This is a cool concept, though this is one problem I'd love to have my self, like scaling to fast. Being overwhelmed by the adoption curve. :) Good luck with the project!

    1. 1

      It's a joyride :)

  14. 1

    Good read. I wonder how the margins play out in businesses like this and how much predictability you can build on your cash flow.

    1. 1

      Good Question. With productized business the margins aren't as fancy as SaaS. Cash flow is super important to manage. As you have to reinvest profits to scale further.

  15. 1

    that's actually insane the hunger he had and the dream he fighted for it good job

  16. 1

    Any way a skilled dev can add value to your team who has worked for Sweden, Spain, Dubai, India, NewYork...

  17. 1

    Product creates value.

    Systems create consistency.

    Distribution creates growth.

    Most founders focus on the first and wonder why the other two never appear.

    1. 1

      Product Led growth is real. However, it has to be an exceptional product which is very very hard. The product has to feel shareable or talkable, so if you launch it to 10 users, they get you the next 100 users and so forth.

      The less risky approach is MVP + Doubling down on distribution.

  18. 1

    This line hit me: "Some of our best decisions came directly from observing frustrating workflows instead of brainstorming startup ideas in isolation."

    That's exactly how Meet4 started. I was in a business networking group where every small group meeting (3 people, find a time, find a place, get everyone to agree) turned into a 30+ email thread over two weeks. Not occasionally. Every single time. For everyone in the group.

    I wasn't looking for a startup idea. I was just stuck in one of those threads thinking "this is insane." That observation became the product.

    We're early, building in public, and nowhere near your scale yet. But your point about distribution before you think you need it is one I'm taking seriously right now. What was the first community that actually moved the needle for Draftss in the early days, before anything was working yet?

    1. 1

      We got our initial customers from Reddit, Indiehackers and Facebook Groups.

      Btw, meet4 has a password protected page is that intentional?

  19. 1

    Focus on distribution earlier. A decent product with strong distribution usually beats a great product nobody knows exists."

    This is the line that stings the most when you're early stage. I'm currently learning this the hard way with a set of standalone HTML tools on Gumroad — the building part was the easy part. Getting in front of the right people is a completely different skill.

    The "start smaller than you think" advice also resonates. I've been tempted to keep adding features thinking that's what drives sales. Reading this confirms it's not.

    Thanks for sharing this — useful reminder to treat distribution as a first-class deliverable.

    1. 1

      Yes, building is easy. Distribution is tough. Experimenting with different channels will give you insights into the best ROI machine for you.

  20. 1

    "The productized service model works because it removes decision friction. When buyers know exactly what they get, the psychological barrier drops significantly. Did you use any specific pricing structure to make the offer feel like a no-brainer?"

    1. 1

      We worked on pricing quite a few times. Almost 2-3 times every year.
      We made sure our offer is competitive and offers a lot of value to the customers.