Ask HN: How to scale MRR as freelance web developer?
I&#x27;d like to give a detailed answer, but I&#x27;m exhausted, so I&#x27;ll link to a Twitter thread for now: <a href="https:&#x2F;&#x2F;twitter.com&#x2F;jugurthahadjar&#x2F;status&#x2F;1310668293305499653" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;jugurthahadjar&#x2F;status&#x2F;131066829330549965...</a><p>One way to go about it is to increase your prices, which could result in fewer clients but fat revenues.<p>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 <i>fast</i> to avoid the usual consulting pitfalls: &quot;XY Problem&quot;, solutionism, inability to define the &quot;Job to be done&quot;, failing to find reasons of non-consumption, failing to involve end users&#x2F;domain experts you&#x27;re building for having only execs&#x2F;managers opine on what needs to be built for their &quot;n&#x27;th level report&quot;, etc.<p>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 <i>ton</i> 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&#x27;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.<p>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 &quot;Does it hurt?&quot; when you put your finger somewhere. Does that really require your expertise? Are you that awesome in doing that that <i>only</i> you can do that? Do you know your client&#x27;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 &quot;ways of extracting problems out of client&#x27;s aches and agony&quot; into a format that is easily consumable by the client. A tool you give the client that allows them to go &quot;Aha, I see... I understand now that we must avoid going directly to solutions with this AI&#x2F;Blockchain&#x2F;IoT thing and focus on the <i>actual</i> problem and come up with a clear question and criteria of success&quot;. 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.<p>You can get to work on valuable things from the first meeting, instead of spending five meetings extracting out the problem. Granted, you&#x27;ll have to round rough edges and clarify some replies to the template, but the work to do is immeasurably less.<p>Refining this is to take the sessions of the problem definition meetings of several projects, and turn them into a &quot;video workshop&#x2F;course&quot; you sell to potential clients that helps them pave the path and do the legwork for the project.<p>If your rate is $2,000&#x2F;day and it usually takes you five meetings plus the people involved... This adds up <i>pretty quickly</i>.<p>Doing this dramatically reduces the &quot;time to value&quot; 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&#x2F;testimonials, which means reputation, which means increasing your rates or coming up with offers for larger customers.<p>Do that <i>systematically</i>, 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&#x27;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 <i>that</i> different and abstract it. Systematically.<p>At some point<p>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.<p>Ask to record videos of the calls to reference later, document, and go back to.<p>After enough projects, patterns will emerge, and abstract those into products. That&#x27;s what we did. We keep our consulting activities to have a finger on the pulse.<p>Sorry I couldn&#x27;t write a more concise and effective reply. Could elaborate at a later time. All the best,