Update: Ali has just released a book on hiring which we at tosbourn would highly recommend!
Ali spends a lot of time thinking about the business of web development, so when he kindly agreed to be part of my freelancing interview series I was excited.
I sat beside Ali at the Lead Developer Conference for a few talks and we got talking. We ended up not hating each other and soon after he invited me to guest on his podcast; The CTO Show. I have a lot of time for Ali and his opinions.
Najaf Ali is the founder and of Happy Bear Software, a software development consultancy specialising in Ruby on Rails. He has barely any idea of what he’s doing. Eventually he hopes one day to learn to tie his shoelaces.
Without further ado, lets jump into the interview;
How long have you been freelancing for?
Depends how you’re counting. I graduated university in 2006 and left for Japan to teach English for a couple of years. This left me with a lot of time on my hands, so I ended up picking up one or two small PHP jobs on Elance (now called Upwork) back then. If we count from there, it’s 2016 now so that’s ten years.
After I moved back to the UK in 2008 however, I got a full-time job as a developer and was continuously employed on a permanent basis until about 2012. I kept the odd freelance project going on evenings and weekends.
In 2012 I took out a £10k bank loan, handed in my notice and started contracting. I had a few freelance clients going at the same time. After a year of that, I had more work than I could handle on my own and decided to hire a developer. That’s how my development agency, Happy Bear Software came into being.
So if we count from 2012 that’s four years. Since about 2014 however, I try to stay out of the day-to-day client work and focus on everything else the business needs to operate.
That means managing and developing the team, lead generation, finance, sales, coming up with new offerings, and about 1.34 gajillian other things required to keep the lights on. I’m not sure you could call my day-job “freelancing” by any stretch, so we might not count the past two years.
So to answer your question, anywhere between two and ten years, depending on how you’re counting.
What services do you offer?
The original service I offered as a freelancer (and our main bread and butter service now) is web development for money. That means you pay me/us money and in return we program computers for you. This still makes up at least 90% of our revenue.
Currently we structure this in terms of developer weeks. A developer week is both the smallest and largest discrete chunk of time you can buy from us. This means we don’t lock clients in for long fixed-term projects. They can end work with us at a weeks notice. It also means we don’t spend days/hours scattered out across different projects.
We also have a number of ancillary services that bring in a bit of revenue and help to keep people doing revenue-generating work during gaps in utlisation. The main benefit of these services to us however is to act as a mututally reinforcing ecosystem of offerings for our clients. This sounds like bullshit management speak, but bear with me.
A client of one of our services might end up contracting us for another one, or end up being a development client, or transition from development to one of our longer term services. This means we have multiple opportunities to provide value to our clients, deepen our relationship with them, and increasing their LTV to us.
Around development, we have two services, positioned before and after a development engagement.
Project Origin is a requirements gathering and roadmapping workshop. We charge clients a fixed fee, and come up with a plan for kicking off their project. This takes the form of a number of meetings, a lot of research/information gathering, very long email threads, and a lot of writing. The deliverables are:
- A project micro-charter giving a one-page summary of the thing they’re trying to do, why they’re doing it, what success looks like, and how they’re going to get there.
- A set of task definitions (or perhaps for the more religious among you, “user stories”) planned out in enough detail that a developer could start work on the first few iterations of the plan.
This plan includes no estimation. At the end of this engagement, the client can in theory take that plan and go to another development team for implementation implement, and we’re totally OK with that. In practice they will most likely end up working with us.
This offering is designed to solve a specific lead-generation/scheduling problem for us. No client wants to talk about starting a development project three months from now. By the time they’re ready to start programming, they want to start right now. This makes it very difficult to do long-term scheduling for development work. We never know where the next project is going to come from and we can’t know until we need the work right away.
This offering finds them at the planning stage, so we have a much longer lead time to development actually starting. Delivering Project Origin can take up to three months in fits and starts, especially if stakeholders on the client side are a bit elusive. This gives us ample time to get our ducks in a row and line up developers ready for project start. Clients are also much more willing to wait for us to have availability at this point, as they’re so much more invested in the relationship with us.
At the other side of the development engagement we have a maintenance and support retainer called Upkeep. Clients pay a fixed monthly fee and get approximately a day per week of work for us on a “use it or lose it” basis. We only allow bugfixes, view level changes, and investigation of production issues during working hours on the retainer. We guarantee an email response time of twenty four hours, but we usually get a response over to clients within about thirty minutes. Officially we say twenty four hours, just incase we have one unlucky day where five retainer clients blow up at the same time.
If the client doesn’t put anything in the backlog and there are no issues, we pop one monthly “episode” off a stack of them that we use on all retainer clients. For example, in month one we might send an email telling them that we want to do a quick high-level sweep of security problems, and all we’re doing for them there is running and fixing brakeman issues. Month two is front-end performance. Month three is fixing broken links, and so on. These tasks aren’t a huge deal in the grand scheme of things, but they let the client know that we’re still alive and we’re delivering value.
The reason we do this is to pre-empt a specific situation on the client side that we know might threaten the engagement. We know that at some point, someone is going to see the retainer as a line-item on a profit-loss statement and is going to ask what the fee bought them. We want our contact at the client side to be prepared with a PDF detailing exactly what got done on the retainer. If that PDF is empty, it will be a much harder sell than if we regularly and pro-actively engage with the client to improve the quality of the software, in whatever small way.
The strategic benefit of the retainer is multi-fold. The most obvious one is that it allows us to continue the relationship with a client on a long-term basis. This means that the next time they’re looking for development work, we’re probably going to be the team they speak to first. Another strategic benefit is that the kind of work involved on the retainer is perfect for junior developers. This means we can hire juniors and have them doing revenue-generating work from day one, building their confidence/skillset up to the point where they can do active client development.
So those are our main development related offerings:
- Project Origin - A fixed-fee roadmapping and requirements gathering engagement.
- Development - Our bread and butter weekly development service.
- Upkeep - Our long term maintenance and support retainer.
But we’re not quite done yet!
At a certain point in my career, for better or for worse, I became known for an expertise in web application security. This started with a talk I gave at the London Ruby User Group a few years ago.
Based on the response to that talk, I created a one-day training workshop that aims to teach developers to find security flaws in web application code. I ran this as a public, ticketed workshop, with a price point of about £300-£400 with about 16 attendees per workshop. This may seem like a lot of money after developing the material, but actually shifting sixteen tickets turned out to be more effort than the equivalent in fees for development work.
This went reasonably well and I ran it sporadically over the course of the next few years. I was asked to run the workshop in-house for development teams, though it took a bit of work to dial in a price-point/structure that was easy to sell[†].
[†] Briefly, teams typically have a training budget and the contact usually wants to take a fixed fee to their superiors for approval without knowing exactly how many people will attend the workshop. A per-seat price for in-house workshops makes that difficult. They also want to be able to show their boss they could get a bit of a discount off the public ticket price. For that reason, we charge a fixed fee of about 10x the cost of a single workshop ticket, and allow them to have as many attendees as they like.
Eventually, we started getting requests to do code audits for Rails codebases as well. We charge a fixed fee per Rails codebase we evaluate. We call this offering a Vulnerability Assessment because that sounds marginally better than “Thorough Code Review”. We got these without much effort, and I did these as and when the work came in.
This year we’ve been exploring everything we could possibly do to generate leads. Our main focus is on referrals, because marketing directly to our clients is quite difficult. Marketing to our referrers is quite easy on the other hand.
In terms of marketing, it’s difficult to differentiate yourself as a developer or development agency based on development skill alone. Everyone and their dog sings the same spiel about testing, agile, and a litany of other “best practices”.
Mostly by accident however, we’ve discovered that literally no one but us provides a security-focused code audit specialising in Ruby on Rails. For that reason, both our workshop and our vulnerability assessments have acted as a “spearhead” that helps us initiate client relationships. We provide them with the security-related service and that naturally follows on to development later.
As I said, this work mostly came in by accident and we worked on it on an ad-hoc basis. However it was so good for lead-gen that I decided this year to polish these offerings a bit and make the security side of the business it’s own thing.
This is still very much a work in progress, but we spun out BearClaw as our “security arm” earlier this year. All this really means is a new marketing website, maybe an email course etc. I’m also trying to be better about running the public workshop quarterly, as it acts as a really good way to market the security services and position us as experts on the topic, whether or not it makes that much of a profit.
That about wraps up our services for now. I have about thirty ideas on the stack that I want to implement eventually, but I’m nowhere near close to getting the services we already have up to the standard/volume of sales I want them to be at.
In future though, it would be great to do for performance what we’ve done for security. I’ve also been toying with the idea of a 1-3 month remote coding course for false-beginner developers that want to get practice solving non-trivial technical problems. I can keep going with ideas all day, but whether we’ll get around to implementing any more of them remains to be seen.
Thanks for the detailed answer! What did you do before freelancing?
Before I was a developer I taught English in Japan. For a year I taught at a Japanese senior high school, and for a subsequent year I taught at a very expensive Eikaiwa school. My students there were high-end business consultants, scientists, celebrities, and staff of the Imperial household. That lead to some fun stories.
I was a rank-and-file developer after moving back to the UK in 2008 for about four years until 2012 when I started contracting.
I really want to ask about those stories, but I won’t! Why did you decide to take the plunge?
For a few reasons, in no particular order:
Firstly, apart from one notable example, I’d had a string of, shall we say, inexperienced managers. This made my overall experience of being employed by someone elses company unpleasant. I wanted to avoid that unpleasantness in future, and starting my own business as a contractor/freelancer felt like a step in the right direction.
Secondly, I thought the money would be better. It turns out I was wrong, because I didn’t really understand business finance. Permanent salaries for developers with roughly my level of experience in London now make far more economic sense than freelancing. Now that I understand business finance a bit better however, I know the money will be pretty good when we get to around six developers full time at around 70% utilisation.
Lastly, I’ve never been particularly excited about being a programmer. I’ve always kind of seen it as my “day job” while I work on business ideas for starting my company. This is analogous to how someone who wants to become an actor might have a day job as a barista (though programmers get paid hysterically more than baristas, so don’t read too much into that metaphor). While freelancing/running an agency may not be what I thought I’d end up doing ten years ago, it’s definitely closer to where I want to be than working as a developer.
How would you describe your first three months as a freelancer?
It was terrible and I hated it. My first contract was all kinds of special. My approach to the work caused a lot of problems, and this ended with me in therapy. However it made me find a really good therapist, so there’s that silver lining.
If there was one bit of advice you could tell your pre-freelancer self, what would it be.
Just one bit? God there’s so much I didn’t know. I had no idea what the hell I was doing then. I mean I still don’t, but I was clueless in uncountably infinite ways then, and I’m clueless in at most countably infinite ways now.
Perhaps the biggest mindset shift for me was focusing less on the monthly, cash-based P/L statement and instead focusing on the annual, invoice-based P/L statement. That’s a fancy way of saying “get some capital (you moron) and start thinking long term”.
What mistakes do you see fellow freelancers making?
- Not spending enough time cultivating your network. All of our leads come from our network of clients, referrers, alumni and other associates.
- Not developing your writing skills. Good communication skills mean that people can get to know you from a distance, and clients will feel better about working for you. A lot of that boils down to your ability and willingness to write.
- Not charging enough. Charge more and you get access to clients with more money, at higher levels in their organisation, that treat you better. Charge less and you get lower values on all those axes. You also have to do more work for the same money.
- Billing hourly. Bill daily or weekly instead. This serves to limit your engagements to clients that can and will book you for larger chunks of work, thereby making planning easier. It also means you don’t have to be shitty about e.g. billing clients for phone calls and the like.
- Not speaking at events/conferences. I’m quite guilty of this. The few conferences I have managed to speak at have always resulted in significant positive outcomes, be that in hiring, conversations, or subsequent inbound leads.
What one thing have you been doing way more of than you anticipated?
Nothing really. I wasn’t really anticipating anything. I knew there would be dozens of things I was so bad at that I couldn’t possibly have known how bad I was at them.
My time is split fairly evenly across admin, lead generation, sales, finance, line management, internal training, and client work that only I can do (i.e. security stuff). This is roughly where I would like it to be, though I’m always trying to hand as much off to our VA or development team as I possibly can.
If you aren’t coding as much these days, how do you stay sharp enough to do your internal training with your team?
So I say I’m not coding as much these days, but I do occasionally find myself at the coalface. Usually:
- All told I do about two or three months of development work per year
- I’m available for reviewing PRs when there’s no one else around and something needs eyeballing
- I’m still doing all the security/requirements gathering offerings mostly on my own
Between you and me I’m occasionally dabbling with Rust, and am still (years later) working through the Matasano Crypto Challenges. So I’m not all that worried about losing my technical abilities just yet.
Have you had to do much marketing to attract new business?
We find it difficult to do marketing directly to our clients because our clients span many different industries and organisation types. The only common thread is that they use Ruby on Rails. It would be much easier to market to them if they were all shipping companies, or all in pharmaceuticals, or all in the fashion industry.
However our referrer is the same person, and all of our clients came via referrers. They’re senior technical people. People in the industry that have at some point programmed for money, and are now in leadership or consulting positions.
This person on the other hand is really easy to provide value to because I am this person. All of our lead-generation activity is based around finding people like this that I get along with and gently increasing engagement with this person over the course of a year or longer.
This might start with meeting at a conference. I might continue a few weeks or months later by inviting them as a guest on my podcast. A few months after that I might find myself writing an interview about my business for them. Later I might invite this person to our monthly invite-only dinner for founders and senior technical people[∑]. I generally want to help this person do whatever it is they’re trying to do in life.
[∑] For those in the audience, this is more or less a step-by-step description of every interaction I’ve had with Toby. That’s why he’s recoiling in horror now.
[Toby’s note: Ali has fallen into my trap of thinking I am in his funnel, he is actually in mine.]
All of this is part of a well defined strategy planned out at the beginning of this year, with the explicit goal increasing referrers, regularly engaging with them, providing them with some kind of value, and making sure they have a rough idea of what we do.
The theory being that if we nail off all of those points, we’ve done everything we can to increase the probability that they will refer work to us when they hear about something appropriate.
I’ll spare you the details, but back of the napkin maths says that we need about 200 such referrers to maintain a rate of one qualified lead per month, for a very long and convoluted definition of “qualified lead”. At time of writing, this is still a work in progress, but appears to be bearing fruit already.
Do you encourage your developers to have a similar funnel for getting in referrers?
Not really. If one of the developers on the team decided they wanted to help out with the lead gen then I would 100% support them in implementing our strategy. This is really the only way I ever get to hand off lead gen to anyone else. There’s no way we’re ever letting a non-programmer do networking/lead-gen/sales on our behalf.
Unlike me the development team do (appear to be) reasonably interested in being programmers, so I think it is unlikely that any of them will want to focus on lead-generation in the way I’ve described above. If it ever happens though I will be ecstatic!
Can you see yourself working for a company again in the future?
Absolutely. I’m way less hesitant to do this now that I’ve run my own company for a while. There are untold creatures in the darkness waiting to stab this company in the throat. Any one thing that I happen to miss or that knocks the business too far out of it’s usual operation could result in the business winding up. I don’t see any shame in this, because running a business is hard.
In that case, I would probably want to lick my wounds and go permanent for four or five years. I’d use that time to build my network, do a lot of writing, and sleep soundly without having to worry about making payroll every month. I would almost definitely get some form of investment for whatever I do next.
Is there anything else you would like to say on the topic?
Yes, tons, but we’re nigh on 3.5k words already so I think that’s enough of me opining for one day!