Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How to scale MRR as freelance web developer?
10 points by codingnils 5 months ago | hide | past | favorite | 6 comments
Hey there,

this is my first post here on HN.

I'm following around HN and Indie Hackers since years and finally started my own company as a side business. Due to COVID-19, I got several small businesses as clients, that needed help for optimizing their website, setting up an online shop and so on.

So I'm offering individual consulting, web development, optimization for websites, online shops as well as individual coding for new web projects.

As we started in june 2020, I got from zero to around $2400 MRR. This revenue is very stable since then, but I want to scale up more.

At the moment, the MRR solely depends on my time and some customers that need additional features/changes.

But my time is limited as I'm the only person right now that runs this business and I have only limited time (as this is right now a side business).

I'd like to scale the business up, by getting more stable incomes. With some clients I already got a long-term contract for simply being "available" for support questions. In my opinion, this is only possible with customers that already trust in my experiences and knowledge.

I see a lot of "consulting businesses" starting with video courses as starter point for customers, but I don't think this might help them a lot, because the consulting I'm offering is more 1:1...

Do you guys have some advices for me, how to achieve a more stable revenue stream from my offers? Like easier subscriptions and getting directly paying customers for my services? What could I do to make more SaaS-like "service" out of this instead of individual consulting?

Thanks in advance for your input and ideas!




> I’m the only person right now that runs this business...

I’ve been amused to discover on a few occasions— a productive and talented Remote Dev contractor we hired, in reality was a 3-5 person team.

Essentially, find others who can help serve your clients.


Some years ago,when I was a project manager, we had someone like that, albeit not in tech.He would always take the jobs,no matter the size and deadline.And he would deliver every single time. Only after a year or so I found out he was working with a partner and most likely shared the workload.


From my personal experience:

If the bulk of revenue largely comes from finding new clients and doing big pieces of work for them (building an ecom store, website, whatever) get good at networking and sales.

Then for every client you possibly can push a SLA/recurring support for emergencies at what seems like 'not a lot' (to them) for their peace of mind and knowing you'll be available to jump on stuff for X emergency hours if needed. Most will never need it (and not at the same time) and you'll build up MRR here.

You can do very well from this, particularly with a couple of very good clients (think big corps; they need a few 'big' (not to you, but they pay good money) builds/projects a year, are happy to pay to know you're 'there' in between).

If you want to scale beyond 'you' (ie become a small agency), again, it's all in being good at sales.


You can scale as an agency or as a SaaS.

As an agency, think of building pods of 2-3 people, maybe a designer + 2 developers. You'll be part of the first pod, so step one is to build your first team. The idea (simplified) is that if you figure your way to 2 pods, then you can scale to 10+.

As a SaaS you want to think to a recurring problem your customers have and automate them. It won't be the full 1:1 consulting, just a little piece. But you may already convert these existing customers.

The two are not mutually exclusive at the beginning in the sense that you can start finding a partner, build a SaaS together part time and see how it works/what you like better.


I'd like to give a detailed answer, but I'm exhausted, so I'll link to a Twitter thread for now: https://twitter.com/jugurthahadjar/status/131066829330549965...

One way to go about it is to increase your prices, which could result in fewer clients but fat revenues.

Second: Systematically factor out anything you do more than a few times. The 1:1 approach means several meetings in which you try to pin down a problem. As you go through projects, you refine the questions you ask that get you to a problem statement fast to avoid the usual consulting pitfalls: "XY Problem", solutionism, inability to define the "Job to be done", failing to find reasons of non-consumption, failing to involve end users/domain experts you're building for having only execs/managers opine on what needs to be built for their "n'th level report", etc.

Extract these questions into a template, with examples of answers and the objective of each question. Send that template to users. This will save a ton of time as it will avoid many meetings which translates directly into a lot of hours of actual meetings, more days of give and take through email to set up the meeting and ensure mutual availability, and the overhead of the meeting (before and after not working on product). Extract anything that is your client's expertise into a package to give to the client to do, and get to a position of doing something the client is paying you to do.

What do I mean by that: the template example. The 1:1 meetings are mostly you helping the client dissipate the fog of their thoughts and identify the problem. Probing and poking around and asking "Does it hurt?" when you put your finger somewhere. Does that really require your expertise? Are you that awesome in doing that that only you can do that? Do you know your client's domain better than them to the point of defining the problem being only possible with your intervention? The answer to all of these questions is probably no. One solution, therefore, is to make the client come up with the answers themselves. How? Packaging your "ways of extracting problems out of client's aches and agony" into a format that is easily consumable by the client. A tool you give the client that allows them to go "Aha, I see... I understand now that we must avoid going directly to solutions with this AI/Blockchain/IoT thing and focus on the actual problem and come up with a clear question and criteria of success". The results they could get with that are great, and your next meeting will include them thanking you for that and telling you explicitly that it helped them a lot to pin point the problem and clarify their thinking process, use clear definitions, etc.

You can get to work on valuable things from the first meeting, instead of spending five meetings extracting out the problem. Granted, you'll have to round rough edges and clarify some replies to the template, but the work to do is immeasurably less.

Refining this is to take the sessions of the problem definition meetings of several projects, and turn them into a "video workshop/course" you sell to potential clients that helps them pave the path and do the legwork for the project.

If your rate is $2,000/day and it usually takes you five meetings plus the people involved... This adds up pretty quickly.

Doing this dramatically reduces the "time to value" of a project and, equally if not more important, ensure you all are aligned and will build the right thing and increase the likelihood of success of the project, which means revenue, which means satisfied customer, which probably means repeat business and referrals/testimonials, which means reputation, which means increasing your rates or coming up with offers for larger customers.

Do that systematically, as in you think about it every day and go through a loop of post-mortems or after-project-report on what worked, what didn't, what question had the greatest and more useful answer, what analogies to use, what structure. Everything goes into refining the machinery. Invariants should go to their irreducible quantity, and then question that irreducibility. Work on a project should only be on whatever is different from the previous projects, and then question whether that is really that different and abstract it. Systematically.

At some point

Reduce degrees of freedom. Meaning the setup for meetings (one usual way to do meetings), meeting minutes template, quote template, etc. You should be able to think only about what is relevant to the project. This should become a machinery.

Ask to record videos of the calls to reference later, document, and go back to.

After enough projects, patterns will emerge, and abstract those into products. That's what we did. We keep our consulting activities to have a finger on the pulse.

Sorry I couldn't write a more concise and effective reply. Could elaborate at a later time. All the best,


Thanks a lot for your feedback! That's a very good point.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: