| tl;dr - s/w product dev shop, few months in business, looking for benchmarks/advice. I'm an experienced engineer and product/eng leader. Earlier this year I started a software dev shop, after having been in engineering and product IC and leadership roles for over a decade. I mostly worked at early stage startups, so my consultancy focuses on helping non-tech founders build MVPs. I work with talented freelancers to do a lot of the dev heavy lifting and focus more on product/technical review/problem solving and play the role of the lead who gets it done well. I also focus a lot on finding new business. I've worked with 4 clients so far but given that I work with founders/early stage cos, they haven't been particularly cash rich projects. Biggest one was 15K spread over 2 months. My margin has roughly been 40-50% on each project so far. Those of you who've been in this business for 2+ years now, I'm curious how it's worked for you and what advice you would have for yourself starting out or for me. My goal is to build a healthy income (200k+) for myself. I'm not looking to build a $multi-million consulting practice but it'd be great to get to a million or high six-figures in billings. How did you grow from a few one-off clients to a healthy pipeline of new business? How does one outgrow this phase where business only comes from your network? How long did it take you to cross $1M in billings/yr? What's the typical client you work with? early stage? mid-sized/large companies? founders? are you focused on a niche? I understand what I'm offering is a commodity service but I try to focus on my USP of bay-area based strong technical leader/fmr founder who you can trust with owning product development. This doesn't scale though - I can't be doing 8 projects. The easier path to the money I want to make would be to just freelance at a high rate but I am looking to grow this as a business, not as a solo practice. Can you share your learnings? |
We've been doing this for seven years and fortunate to have been profitable from the start. Now building our machine learning platform[2] to streamline this and solve actual problems we faced in the real world doing real projects that enterprise clients has paid for. Some projects took us longer than what we think their irreducible duration should have been. It is important to always remember so one does not build a product around imaginary workflows, or around workflows that never produced actual paid products. i.e: when you abstract something into a product, it helps to leverage your domain expertise and it helps having shipped paid product in that space. This is a reminder to people who go into something from a different background and think nicer stylesheets/UI will solve things, or assume people in a domain are morons who never heard of "the cloud" or "Kubernetes". Sometimes you may even have to remind your team looking at other products and wanting features: have we actually ever faced that in real life or is this Aikido stuff/Don Quixote battling imaginary adversaries/problems?
Why: at some point in your consultancy, you'll notice that certain patterns emerge and that you can solve certain classes and clusters of problems you faced delivering software itself with software. That product will help you tremendously if you build it.
Happy to answer questions.
- [0]: https://mobile.twitter.com/jugurthahadjar/status/13106682933...
- [1]: https://news.ycombinator.com/item?id=24972611
- [2]: https://iko.ai