从自由职业者到7位数ARR的产品化服务创业之路

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. 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.

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.

Advice for founders

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.