A year after launch, I’m winding down Parable to build something new. Life has taught me that repeated failure is often the price you pay for eventual success with anything, so I expected to be writing this post sooner or later. While I’ll admit it stings a bit, there were numerous reasons for me to call it quits. I’ve detailed the big 3 below.

The reasons

Real reads weren’t all that useful

Parable’s headline feature was that it could show you how many people were reading your content, rather than just how many visits your content was receiving. It also included tools tailored for content analysis - traffic sources, scroll depths, reading times, focus break frequency, and browser stats (to name but a few!).

The information Parable surfaced was useful to have, but it was just information. Parable couldn’t automatically get you more readers, and it couldn’t even tell you how to get more readers. Its usefulness relied entirely on you finding value the information it surfaced, and I overestimated how much that was worth to people.

As an example, knowing how many real reads your posts has isn’t useful in isolation. It only becomes useful when you measure its change over time to see that your continued efforts to improve your writing are resulting in more reads. However, this change can just as easily measured using a less granular metric like visits, available from any general purpose web analytics product.

Deeper insight wasn’t always necessary

I spent a few thousand pounds on various marketing exercises for Parable with little payoff, and so I decided to do what I should have done to begin with, and talk to writers about the product. Messages were mixed, but two things became clear.

The first was that new bloggers don’t look for standalone analytics products for their writing. They’ll use the built-in analytics on their blogging platform, or Google Analytics if they need something more complex. They’ll check these every once in a while as they work to get their visitor numbers up, and this will be enough for them.

The second was that professional writers were much more likely to use a range of analytics products, but they were also much more concerned with being able to sell the performance of their content. A product that tells them the 10,000 visits their post had actually only yielded 100 real reads wasn’t going to impress the people paying them, even if it represented a more honest analysis of the content.

Different needs for amateurs and professionals

Following on from talking to writers, I talked to Parable’s users directly. In doing this, I learned amateur bloggers repeatedly failed to understand graphs, heatmaps, distributions and other reports essential to getting value from the product. The information surfaced in Parable wasn’t accessible to them, and so wasn’t actionable, and therefore wasn’t valuable.

Conversely, when I talked to professional writers using the product, they’d frequently ask if it could do more. They’d want to cross reference, break down, export data, and generally visualise things in a number of different ways that weren’t currently supported and would take a lot of rework to implement.

Parable wasn’t simple enough to be accessible to new bloggers, and wasn’t full-featured enough to provide value to professionals. I should have done more market research at the beginning, avoided wasted time, and focussed on a product for the better market (professional writers).

The lessons

While I’m disappointed to be shutting Parable down, I have no regrets about the time I spent working on it. There are plenty of common mistakes I’d theoretically understood around market validation, time management, and solo product development that I still managed to make while launching the product. However, having experienced this pain, I now feel experienced enough to spot earlier and with more clarity next time. Here’s what I’ll do differently in future:

• Spend more time understanding problems before even thinking about technical solutions.
• Seek feedback on solutions early and continuously from potential customers.
• Sell solutions early, even if it means doing things manually to begin with.
• Establish productive marketing channels early, and nurture them continuously.

What I’m not going to do next time is worry so much about developing software. Even with an analytics product, writing Parable’s software and scaling it to handle thousands of requests per minute was by far the easiest part of the journey - sorry technical founders!

If you’re interested in reading more about Parable, I’ve left the marketing website up. I make a living by helping companies bring digital products to market with solid foundations, room to scale, and costs under control. If it sounds like I could help you, have a look over my services. If you'd like to hear more from me, you should follow me on Twitter, for more product development content in future.

I’m currently marketing myself as a developer who helps “bring digital products to market”. This has resulted in some solid enquiries, and I’m fortunate to be in a position where I’m turning good opportunities away, but casting such a wide net has caused problems.

At the moment, I’m doing a wide range of work for different clients. There’s back-end development, front-end development, architecture, documentation, product planning, and more. All of this happens using a variety of different languages, frameworks, platforms, and industries.

From a business development perspective, the knowledge and experience I’m garnering today rarely dovetails cleanly from work I did for previous clients. I’m not developing a true expertise in any one area as quickly as I’d like, and my value proposition isn't as strong as it could be.

Taking on too many problems

Throughout my first 6 months of freelancing I’ve been a bit of a “yes person” to the clients I work with. I’ve tried to help with every problem they’ve had in order to remain as useful as possible.

Unfortunately, this has led to a frantic style of working where progress towards important major goals is slowed by unimportant, but urgent “could you just” tasks. This has hurt me in several ways:

1. It promotes frequent costly context switching.
2. It builds an unhealthy dependence on me in my clients.
3. It pulls me away from important long-term problems, diluting my value.
4. It encourages more of the same behaviour in future.

Charging too little

I’ve tried to use value-based pricing as much as possible over the past 6 months. This means that rather than charging based on how long something will take me, I try to charge based on how much value the work will generate for the client. The idea here is that the amount I charge can be disconnected from the time the work takes to complete. For a large client, this could mean I'm able to comfortably charge a much larger price.

On the small projects value based pricing has worked on, it has resulted in strong win-win outcomes for me and my clients. However, more often than not, I’ve vastly underestimated the amount of my time a project will take, and have felt obliged to complete it at the price I’d quoted. Whenever this has happened I’ve ended up demotivated and resentful over having to work on those projects while turning down other interesting opportunities due to lack of availability.

Being a poor self promoter

It’s easy to let marketing activities slip when you’re barely getting through your client workload each week. I knew this before I started freelancing, and so I worked hard to keep up with regular content creation, social media posting, and light networking in the first few months.

This served me well, but making the time and thinking of valuable things to share became increasingly difficult as summer progressed, and my marketing activity eventually dropped off a cliff at month three. My weeks were already full of client work, and rather than sacrificing some of that to ensure I could continue to attract new business, I buried myself in my work.

Not finding a healthy balance

If you’ve been reading any of my monthly updates from the past 6 months, you’ll know I’ve been struggling with burnout. I thought I’d been burnt out before, but I can safely say now this was very clearly my first time. It’s an utterly pernicious condition, and unchecked I can absolutely see how it could being catastrophic to a career.

I’m not sure on the root cause of my burnout as I work a fairly regular 40 hour work week, but before September this year I hadn’t really taken meaningful time off in 18 months, and a lot of my non-work time has been spent locked down at home not seeing people. I’m choosing to believe these factors, set against a backdrop of existential climate dread and economic uncertainty, contributed to its development.

Wrapping up

When I started freelancing, I privately set myself a goal of invoicing £100,000 in my first year. 6 months in, that goal still seems achieveable for me, but to grow I’ll need to do more than just take on more work.

With that in mind, my plan for the next 6 months is to learn from the mistakes I’ve highlighted above and make the changes required to better position myself in the market, market my services, service my clients, and maintain my mental health.

If you’d like to see how this goes for me, you should follow me on Twitter where I’ll be posting smaller short-form updates on my freelancing between larger 6 month blog posts from now on. I also have a RSS feed on this site if you’d just like to keep track of new posts on this blog.

Stats for August

Revenue

I issued invoices for £6,200 (~$8,579) excluding VAT in August. These came from a mixture of consulting and development work for two different clients, all of this work was billed on an hourly basis.

Enquiries

I received 3 new work enquiries in August:

• My first enquiry came from a business in the Netherlands looking for development assistance. I didn’t have the availability to take this on, but after sharing some speculative pricing with them they indicated that I would have been too expensive for them anyway.
• My second enquiry came from a former colleage who was looking for a trustworthy developer to potentially help with a development project later this year. I indicated that I probably wouldn’t have availability, but otherwise this is still open.
• My third enquiry was from a former client looking for some technical consulting on their rapidly growing startup. It looks like we’ve managed to work out a good arrangement here, and so I’ll be spending whatever spare time I have each week helping them from early October.

Marketing

I put together a small blog post about software testing and tradeoffs in August which did ok, with about 100 views from a social sharing on Twitter and LinkedIn alone.

I prioritised paid work over a social media presence in August to help avoid the feelings of burnout I’ve been experiencing recently. Due to this, my Twitter stats for the month were poor.

I need to do better with my marketing efforts if I’m to see meaningful improvements in these numbers. However, while I have work to do and enquiries coming in for more work than I can take on, I’m not too worried.

Avoiding burnout

The feeling of creeping burnout I mentioned in July’s update was still there in August. I’ve been tired, slightly brain fogged, and have struggled to concentrate. I’m still motivated to do work, but staying focussed enough to do it is proving difficult, and the sense of purpose isn’t there like it has been.

As a freelancer, clients dependend on me being available and consistent. Knowing this creates a strong temptation to work longer hours in order to make up for my own inefficiencies. However, if I were to do this, I’d be left with a vicious cycle of work followed by burnout, followed by more work, followed by more burnout. It wouldn’t fix anything.

Instead, I’ve been reducing my work quantity to preserve work quality. I’m taking less on than I normally would each day, but I’m using a full normal working day to do it. This means invoicing less than I otherwise might, but it preserves client expectations of quality, and puts me on a positive track to get back to normal.

In addition to reducing my daily workload, I’ll also be using a holiday I’ve booked for the second half of September to take a break from technology, trying to keep my screen time (across all devices) to under an hour a day. I’ve no idea if this will make a difference, but it feels like it might.

Goals for September

My goals for September are fairly simple and focussed on avoiding burning out.

1. Maintain work quality over quantity.
2. Use my holiday time to rest up and avoid the Internet as much as possible.

That’s all for August! You should follow me on Twitter if you want to see how this freelancing adventure develops for me. I also have a RSS feed on this site if you’d just like to keep track of new posts on this blog.

Automated tests are an extremely effective practice in software quality control. They can be written once, maintained as the codebase evolves, and be effortlessly re-run an infinite number of times. Tests can automate the equivalent of hours of manual testing in minutes, and I'm a strong supporter of them, but they have their drawbacks.

Tests cost money to write, money to maintain, and can be painfully slow to run at scale. In many teams, intermittent test failures can also hold up deployments for hours while frustrated developers figure out what's wrong.

We often forget that tests don't actually guarantee anything. When they pass, they're just telling us that our potentially buggy test code has determined our potentially buggy application code is behaving as expected under the conditions we thought to check. There's a lot of room for false positives (and negatives) there.

Unfortunately, relying on poorly maintained test suites as the only means of quality control means many teams suffer through 50% or more of their developer's code time being lost to test maintenance. To improve the situation, we need to recognise our tests are just one of many tools we have available.

Making tradeoffs

In order for a test to be worth having, the ongoing cost of development and maintainance needs to be significantly lower than the ongoing cost of not having it at all. This tradeoff isn't always worth making.

Rather than defaulting to tests for everything, we should look at how our application is going to be developed and used, and think broadly about the various tools we have available to maintain quality. We can then compliment lean, valuable test suites with tools and processes that allow us to maintain quality while keeping the tradeoffs working very much in our favour.

An example could be needing to support Internet Explorer (IE) on a single-page JavaScript web application. It would be tempting to make the tests run against IE in addition to modern browsers, but in doing so we'd increase the test suite runtime, and we'd force developers to cater to the quirks involved in automating multiple browsers going forwards.

Since only a small number of our customers are likely to still use IE in 2021, a better approach might be to use an error tracking service to alert us to any IE errors raised in the live environment. This way, the occasional IE user might stumble on an error, but they can be quickly identified and fixed around other work. It's a much more sensible tradeoff between application quality and ongoing cost.

Tools and processes for code quality

Looking beyond tests, there are many tools and processes available to us that we can use to maintain software quality. Many of them are things we do already, but don't use to their full potential. Here are a few I regularly encourage teams to do more of:

• Improving developer documentation.
• Spending time planning new features.
• Spending time on architectural discussions.
• Frequent pair programming.
• Improved code linting.
• Introducing code typing.
• Better code review.
• Targeted manual testing.
• Periodic accessibility and user experience reviews.
• Improving application logging.
• Using an automated error tracking service.
• Using an application metrics monitoring service.
• Using (or understanding) a product analytics service.
• Developer experience improvements.
• Proactively removing old/unused features.
• Proactively collecting customer feedback.

None of these are a complete solution to quality, and each of these have their own tradeoffs to consider. Rather than replace tests, they can be used together with tests to provide a more complete approach to maintaining quality software. They can help to restore a healthy tradeoff between feature development and quality control, enabling developers to iterate quickly and ship with less frustration.

So, next time you find yourself spending the majority of your development time tending to a test suite, consider what other tools and processes you have at your disposal to improve software quality, and make some better tradeoffs.

I make a living by helping companies bring digital products to market with solid foundations, room to scale, and costs under control. If it sounds like I could help you, have a look over my services. If you'd like to hear more from me, you should follow me on Twitter, for more product development content in future.

Stats for July

Revenue

I issued invoices for £11,800 (~$15,575) excluding VAT in July. These came from a mixture of consulting and development work for two different clients. My revenue was so much higher in July because I was finally able to invoice for a long-running piece of fixed cost work I'd been doing part-time since April. This single invoice accounted for about 50% of the total revenue for July.

Enquiries

I received 1 new work enquiry in July from a semi-local company looking for some straight-forward React development help. I had to turn them down due to lack of availability, but it's important I keep these enquiries coming in as knowing the opportunity is there gives me the confidence to say no to things I don't want to do, and a peace of mind that's hard to come by for the self-employed!

Marketing

One of my goals for July was to write a blog post focussed on product engineering. I'm disappointed to say I failed to make the time to write anything, and so unsurprisingly my site and blog posts received about the same number of views as they did in previous months - 1,160 views for the website, and 596 for blog posts.

I also neglected my social media activity in July. On Twitter, my tweets, impressions, profile visits and mentions were all between 50-80% lower than June - eek!

Building a different product

In June's update I wrote an entire section on a product idea I wanted to pursue. The product was going to allow people to sell online events or content in an auction-style setup, with customers bidding for access.

After reflecting on this, I've changed my mind, and am instead going to look at building a small indie analytics platform that helps writers monitor and build an audience by providing some deep insight into who's reading their posts. This was my runner-up idea in June, but I've decided it's actually the best option for me personally:

• Analytics is a proven market.
• The idea excites me more.
• The idea is easier to explain.
• It's a product I would use myself.
• It's more visual, and so easier to share progress on.

I intend to break ground on this in August, defining a tight scope for a first launch, and making some technology choices.

Flirting with burnout

I felt a little like I was flirting with burnout for much of July. Trying to wrap up old projects, continue ongoing work, move forward a product idea, write blog posts, and think of insightful things to Tweet about all got a little much at times.

Rather than trying to keep up with it all, I made the sensible call and let my writing and Twitter activity slide in order to keep working hours normal. Although this is probably good for me, it often doesn't feel good. I'm someone who gets job satisfaction from completing tasks, so accepting I won't finish something I set out to achieve can often be stressful in itself.

Goals for August

With that in mind, I've decided I'm only going to set goals each month that contribute towards my long term objectives of building an audience for my consulting work, and growing a successful digital product. This way, I can put something off for a month without it being perceived as a failure, because the goals will always be relevant. Here are my goals for August:

1. Write a blog post focused on product engineering.
2. Scope out a first release and make technology choices for my analytics product.

That's all for July! You should follow me on Twitter if you want to see how this freelancing adventure develops for me. I also have a RSS feed on this site if you'd just like to keep track of new posts on this blog.

The stats

Revenue

I issued invoices for £6,700 (~$9,200) excluding VAT in June. These came from a mixture of consulting and development work for two different clients. As with previous months, this covers my household expenses and savings goals just fine, so no problems there.

As in May, June's revenue figure represents only the work I billed on an hourly basis. A lot of the other work I did in June is being billed on fixed-cost basis, meaning I won't be able to invoice for it until it's finished later in July or early August.

Enquiries

I received 1 new work enquiry in June. It was from a London-based company looking for some help developing new software for a commercial IoT (Internet of Things) device. It seemed like it would be an interesting project, but unfortunately I had to turn it down due to a lack of availability.

Website visits

My site homepage received 1,192 page views in June. Like last month, there's been no significant change here. I'm fine with this, as building any sort of traffic there is going to be a really slow burner, and it's currently just a brochure site for prospective clients.

Posts visits

My blog posts received a combined total of 549 views in June, which is rather poor. Although some of those views came from traffic to older posts, which is always a good sign that people are actually reading things, the two posts I wrote in June flunked a bit.

My most recent post, "How much does it cost to make an app?" answers a commonly googled (and asked) question. It's really targeted at prospective clients, but has so far only been shared with co-workers and Twitter followers, and so hasn't been read much. I'm going to see if I can change this by sharing it on LinkedIn, and perhaps some Q&A sites where it might find a more receptive audience.

Earlier in June, I completely screwed up by sharing May's freelancing update right before Apple's Worldwide Developer Conference kicked off:

It turns out perhaps people do care about the WWDC. That Tweet got missed almost entirely, and just 13 people looked at that post in the entire month.

Twitter

Twitter stats were up across the board in June, although just 5 new followers this month:

If I'm honest, trying to figure out what strikes a chord with anyone on Twitter is one of the least favourite parts of my work. I'm struggling to find valuable things to share because a lot of the work I do just isn't particularly visual or interesting. I'll keep on trying though, as this is something I'm determined to figure out.

Choosing a product idea

One of the goals I set for myself for June was to choose a product idea to build. After much deliberation, I've settled on something I think could succeed, and which I could reasonably develop, launch, and maintain by myself.

The product would allow people to sell online events or content in an auction-style setup, with the public bidding for access. Targeted at those with a high demand for their time and knowledge, the platform would essentially give them an easy way to generate revenue by simply sharing a link with their audience and waiting for bids to roll in.

For example, if I were a well known expert on a particular technology and I wanted to run a video workshop, I could quickly configure a link with 10 seats for auction on it and tweet a link to my followers. They could then bid on access to the event, with the top 10 highest bids being invited to participate.

The use cases I envisage this working for are various permutations of [in-demand person] selling access to [scarce resource] online. For example:

• A tech influencer selling 10 seats to a video workshop on some new framework.
• A famous band selling a series of one-on-one Q&As with the band members.
• A well known game developer selling 50 early-access invites to their title.
• A highly sought-after consultant selling a spare half-day of their expertise.

I've no idea if this is a good idea or not yet, so my next steps are to hone the pitch, and then make contact with some potential sellers on the service. I'm going to ask them directly if they'd use it if I were to build it, and if this goes well, I'll begin planning in earnest.

Reflections and goals for July

Overall I was pleased with how June went, but everything was ok without anything being great. I'd like to have a win on the content creation or audience building front sooner or later, as this takes up a huge amount of time and energy. To get there though, I may just need to keep experimenting and see what works for a little while longer.

I have a busy July ahead of me with a few days booked off for various activities now that Covid restrictions are loosening in the UK, so I'm keeping my goals fairly simple to ensure I have enough time for work:

1. Get 10 responses to a “Would you use this?” question from well known tech influencers who sell educational content online.
2. Write another blog post focused on product engineering.
3. Outsource or stop doing 3 low value, time consuming activities.
4. Finish my fixed-cost development project and invoice for it.

That's all for June! You should follow me on Twitter if you want to see how this freelancing adventure develops for me. I also have a RSS feed on this site if you'd just like to keep track of new posts on this blog.

I mentioned in April's update that I was working more than full time hours in order to keep up with everything. That was still the case in May, but I was able to spot a few low value requests early, and either delegate or refuse them. Progress!

Despite working more hours than I'd like, May was still enjoyable. Getting comfortable with the idea that I'm no longer tied to a 9-5 schedule has lead to some nice spontaneous dog walks, early starts, late starts, and outdoor lunches. I even took a week off!

The stats

Revenue

I issued invoices for £4,200 (~$5,950) excluding VAT in May. These came from a mixture of consulting and development work for three different clients. If you read the April update, you'll probably have noticed this is a £3,600 drop from last month. There are a couple of reasons for this:

1. Time off: I took a week off in May, and when your income relies on you being at your computer, weeks off are expensive. I only took 5 days, but the time lost travelling, catching up on emails, and other small non-billable tasks in addition to those days really put a dent in my billable hours.
2. Fixed cost work: One of the projects I'm working on is priced on a fixed-cost basis. I put many hours into it in May, but I won't be paid for it until later this year. My other work is invoiced on an hourly basis, and so I invoice whatever time I've spent on it at the end of each month. It's this that you see invoiced for May above.

Despite the lower number, I'm happy with revenue for May. It's enough to cover my saving and investment goals, and the drop was entirely expected and normal.

Enquiries

I received 1 new work enquiry in May. It was a respectable lead, and one that I was incredibly well positioned to help. However, there was a direct conflict of interest with my largest client, and so I turned them down gently in order to avoid a situation I'd feel morally uneasy about.

The consulting enquiry that I previously mentioned I was keen to move forward with in April's update seems to have lost its momentum in May. Knowing the company, I suspect this is them just being busy with other things rather than changing their mind, so I'm going to reach back out to them in June to see if they're ready to move forwards.

Website visits

My site homepage received 1263 page views in May. This is a few more eyeballs than last month, but nothing significant. I expect driving this number up in a significant way will take months and years of effort.

Posts visits

My blog posts received a combined total of 3144 views in May. This is a huge 2.8x improvement on my April numbers, and largely comes down to some lucky retweets:

I'm obviously pleased with this, but it's important for me to remember these people aren't my readers. I need to keep my head down and keep producing valuable things to build an audience of my own.

Twitter

I managed to tweet every working day in May. It continues to feel like hard work, but I did manage to gain 26 new followers this month, so maybe that's progress:

My new followers seem to have come early in the month as a result of some well received Tweets, plus a some chance retweets from 2020. Apart from the new followers though, my stats are down across the board for May due to the week off.

All things considered, I'm pleased with my Twitter progress for May, I'll keep at it throughout June and see where I end up!

Goals from last month

I set myself 5 goals for May based on my reflections from April. I'm pleased to say that I managed to complete all 5:

1. Take a week off.
2. Write a blog post focused on product engineering.
3. Tweet every working day, trying to be insightful.
4. Generating 3 product ideas that I think could work, and analyse the viability of each.
5. Generate enough revenue to cover living expenses and investment goals again.

There's no need to go into detail on most of these, but I thought you might be interested in my week off and product ideas.

Taking a week off

After living indoors since November, we spent a week in Cornwall eating pasties, drinking cider, and doing big clifftop walks. It was beautiful:

If you're feeling a spot of burnout from the past 18 months, I'd highly recommend doing something like this to get perspective and clarity. It always takes me a few days to get out of work mode, but once I do, I can really begin to decompress. Within days, my brain begins to make sense of things that have been bothering me, and the way forward becomes much clearer on various fronts.

Generating 3 viable product ideas

I really struggled with this goal. Ideas come to me easily, but I usually convince myself they're not worth pursuing for one reason or another. To ovecome this, I introduced some constraints to act as a filter for ideas that could work well for someone like me - a technical solo founder looking to build an additional revenue stream:

• Simple but growable: The product needs to be simple enough that I can launch and develop it on my own, but have some trajectory for growth.
• Clear value: The product's value needs to be clear to see so it can be effectively marketed.
• Low support needs: The product needs to have low support needs, or support that I could easily outsource.
• In a proven market: Finding product-market fit is hard, better to build a fresh take on an existing product which has done that work already.
• That I will use: I'd like to solve a problem that I have myself so I can spot bugs, issues, and opportunities in the product.

With those constraints in mind, here are the 3 front-runners from a series of ideas I had this month:

• A simple, private analytics platform for long-form content. This would allow content marketers and bloggers to see how much people are actually reading their content, and where readers drop off, skip sections, etc.
• A blogging platform that allows you to own your content. Too many popular blogging platforms don't allow users to truly own their content. I'd like to see a compelling product solve that, and a few other common blogging platform issues.
• A product that lets people to put together online events that can be bid upon. For example, to let a consultant sell an hour of their time to the highest bidder, or let an tech influencer run a workshop for the 10 highest bidders.

I've not made a decision on any of these yet, I'm going to do more thinking and investigation over June with a view to comitting to giving one a try.

Goals for June

I'm feeling fairly refreshed and motivated at the moment, but have a busy couple of months ahead with client work. With that in mind, I've given myself just 4 goals for June:

1. Write another blog post focused on product engineering.
2. Tweet every working day, trying to be insightful.
3. Choose a product idea to build.
4. Outsource or stop doing 3 low value, time consuming activities.

That's all for May! You should follow me on Twitter if you want to see how this freelancing adventure develops for me. I also have a RSS feed on this site if you'd just like to keep track of new posts on this blog.

When I started working on the web in the mid-noughties, we lived in a world of separate applications and technology stacks. The web was widely accessible on desktop computers, but the mobile web wasn't really a thing yet, and other Internet connected devices like tablets and smart speakers were still years away from becoming mainstream.

In the noughties, web developers were expected to have good HTML and CSS knowledge, and with a back-end language and some light JavaScript and SQL thrown into the mix, you could comfortably build quality web applications. You still can, in fact, but building in directly in these languages was much more common back then.

From 2008 to now, mobile devices have become the default way the web is used, and the Internet has become a sort of “extension of consciousness” for many people. The proliferation of the web has led to new performance, UX, and accessibility concerns, as well as expectations of instant handoffs between devices and seamless integrations between the complementary products.

Changing expectations and advances in technology have meant the past 13 years has seen a tremendous surge in demand for web application development, but also for technologies that allow us to build digital products that do more, run across multiple platforms, and connect seamlessly with everything else. Boundaries have become increasingly blurred, and the demands on the web as a platform and the developers building for it have grown significantly.

Changing priorities

New languages, tools, frameworks, services, platforms, architectures and development approaches have quickly gained widespread traction to make building for the modern web easier. Many of the most well known of these have grown out of large tech companies, who develop them to solve their own problems and then nurture them into the mainstream where they become de-facto industry standards.

These technologies abstract away from low-level detail so developers can build more efficiently across a wider range of devices in a connected way. They protect developers from solved problems, and integrate seamlessly with pre-packaged solutions for common problems. This lets developers spend more time writing code that tells systems what to do, and less time writing code that tells systems how it should be done.

This abstraction has, in turn, led to a subtle change in skills valued by organisations hiring new developers. Nowadays, breadth of experience in shipping solutions is generally valued over depth of expertise in specific areas of technology. In short, knowing that a solution works is seen as more useful than understanding why a solution works.

On the web, I've seen this change in values reflected most strikingly in junior developers. When I started working in the industry, I'd see other junior developers like me starting work with decent programming language experience, but little framework or tooling experience. In 2021, it's more common to see a specific set of platform and framework experience, with little, or sometimes no experience in the underlying languages involved.

The quality problem

Most would agree that having a chef who can reliably produce a tasty meal is more useful than a chef who understands the chemistry of cooking but produces inedible food. In the same way, we're right to value developers who can produce working software, but I believe we've crossed a line into a “too much of a good thing” situation with the tools we use.

Today, many developers are consistently working several automated abstractions removed from the code they're actually shipping, and doing so without the knowledge required to diagnose and resolve quality at lower levels when they inevitably do occur. I see this causing the following major problems all over the web:

• Poor application performance: Nested webs of dependencies, transpilation and bundling steps mean many megabytes of unnecessary assets end up in production where they need to be downloaded and processed on connections and devices much slower than the ones they were developed on.
• Poor user experience and accessibility: UI frameworks and component libraries allow developers to build user interfaces without knowledge of HTML and CSS, leading to div soup, inaccessible markup, and unmaintainable stylesheets. This is done without any consideration given to UX or accessibility.
• Persistent bugs that linger without a fix: A lack of low level knowledge means that often nobody in a team is able to competently dig into their stack to figure out what's going wrong. It's less costly to just ignore the bugs until they become a bigger issue.
• Gaping holes in application security: A lack of awareness of the underlying technologies leaves applications and APIs littered with security vulnerabilities that put confidential data at risk.

The interesting thing about these issues is that organisations are generally aware of them, but blame them on individual laziness or limitations in capability. Ironically though, this conclusion is itself the result of lazy thinking.

The reality is most developers have areas they'd love to build deep expertise in, but for many teams, the constant pressure to ship combined with the routine demands of of their personal lives means they're forced to work in a feature factory, only ever picking up tidbits of “how to do x” knowledge here and there as they go, and leaving a trail of unfortunate quality issues in their wake.

Improving the situation

It's common to see purist influencers advocate for a back to basics approach to solving quality problems. They encourage developers to build applications using clean hand-crafted code and few external dependencies that really get them working close to the browser or some server-side environment - “Look how far you can get with just the basics!”.

Back to basics is a great way to learn, but it's an uneconomical approach for building larger applications in most businesses. The frameworks and libraries people bemoan for their wastefulness are so popular because they're actually not wasteful at all. They're highly efficient on developer time, which is usually a much more significant cost than an inaccessible or slow web application in your average-sized company.

With time in mind, we need to approach the quality problem in a way that preserves the flexibility and bang-for-buck efficiency of modern development, while enabling developers to steadily grow the lower level expertise they're missing within work hours. In my experience, this works well through a combination of automated monitoring, deep learning time and personalised learning areas.

Automated monitoring

Automated monitoring tools are fantastic for detecting and alerting developers to quality issues with their web applications. User acceptance testing, cross-browser compatibility, performance monitoring, bug tracking, accessibility and UX regressions can all be automatically monitored to varying degrees.

When the pressure is on, automated tooling helps to keep everyone aware of the overall health of a suite of applications, and enables teams to focus on shipping with their favourite high level frameworks while being alerted to many major quality issues ahead of time.

Deep learning time

Many companies make nominal gestures towards supporting employee learning, but it usually comes second to everything else.

Learning is important, and to build deep expertise, developers need dedicated time and support from employers to build their knowledge within work hours. This dedicated learning time can be combined with a small budget for books, courses, workshops, and conference presentations for even greater effect.

Lastly, the importance of this learning time needs to be elevated to a position whereby it isn't skipped the moment a minor issue occurs, or the team falls slightly behind on their sprint.

Personalised learning areas

Rather than encouraging everyone to learn everything, speak to your team members and figure out what interests them on an individual basis. From there, you can set goals for building deep expertise in specific technical areas that align with quality issues the team is struggling with.

This way, even a small team can build real expertise in areas like performance, user experience, accessibility and security. They can begin to keep on top of quality issues while still shipping features quickly.

Wrapping up

By fostering an environment that promotes developing deep expertise alongside higher level productivity, you're creating a team that's better equipped to efficiently build modern, highly integrated applications across a diverse range of technologies and high level frameworks that shine as examples of quality software.

What's more, you're also taking an active role in aligning your developer's interests and desire for mastery of their craft with benefits to your organisation. This is a major motivator for employees in an industry where impostor syndrome or a general feeling of falling behind are very real fears for many.

If you're still not convinced, just remember that these benefits compound over time. Individual learning builds into very real expertise that spreads to others in the organisation, and happier, more fulfilled employees will attract higher quality applicants to your business who will in turn do the same to others. It's a virtuous cycle that starts by giving people room to learn.

I make a living by helping companies bring digital products to market with solid foundations, room to scale, and costs under control. If you enjoyed this blog post, you should follow me on Twitter, for more product development content in future.

In my first month of freelancing, I issued invoices for £7,800 (~$10,775) excluding VAT. This has come from a mixture of consulting and development work for three different clients. I'll be tracking this figure each month so you can see how it changes over time.

I'm pleased with my first month's revenue. It's is enough for me to comfortably cover my household expenses and monthly investment contributions with some cash left over for saving and spending.

Although this is a good start, it's important to remember that not all of this is take-home pay. There are a lot of additional costs to account for as a self-employed person:

• Service subscriptions
• Accountancy fees
• Service fees (other freelancers, agencies etc.)
• Equipment
• Business taxes
• Personal taxes
• Pension contributions
• Sick pay
• Holiday pay

Lastly, for anyone else looking to start freelancing, I should stress that all the client work I did this month was already lined up before my freelance switch. If April were a complete cold start for me I'd probably have invoiced nothing, and would be using savings to cover household expenses.

Enquiries

I received 2 new work enquiries in April. A lovely surprise! I think they were probably triggered by me announcing myself going freelance, and in doing so, hinting at some sort of availability to the world.

One of the enquries was a referral from a former colleague. The prospect was looking for consultancy and development for a new digital product for their mid-sized national organisation. Unfortunately I had to politely turn this down, due to lack of my own availability over the coming months.

The second enquiry was for some light strategic consulting work from a company I've worked with previously. This looks like it will go somewhere, as the work is a good fit for me, the trust with the client exists already, and the time commitment isn't huge. Happy days!

Audience building

Website

My site homepage received 1137 page views in April. I'm not too bothered about numbers here right now, I'm just trying to grow organic traffic to the site, and the number of prospective client visits through good SEO and targeted content creation.

Blog posts

My blog posts received a combined total of 749 views. Again, it's the first month, so the numbers don't mean much yet. I'm more concerned about blog post views than website views though, as building a collection of valuable and regular content is a long term goal of mine.

At some point, I want to set up some sort of time-on-page analytics for blog posts, so I can tell if people are actually sticking around to read things in their entirety. If they are, this signals to me that I'm publishing things that are worth their time, and generating some sort of value.

Twitter

I'm not a natural self promoter, so I find any sort of regular Twitter presence very difficult to stick to. However, it's proven to be a great tool for audience building for a lot of people, so I've made a real effort to Tweet more in April.

I've tweeted at least once almost every day, and have tried to focus on sharing relevant, useful content with a bit of non-work content mixed in to humanise things. It feels like a lot of hard work for not much return right now. I've had a few likes here, the odd reply there, and a massively impressive… 2 new followers.

Rather than let very mediocre performance deter me, I've been using Twitter analytics to focus on impressions, engagements and profile views from the content I share, rather than followers, which are a bit of a vanity metric. My thinking is that if I can drive engagement up with non-grifty content, the numbers will eventually begin to compound upwards. Let's see.

Reflections

I took on too much in my first month of freelancing. I was able to keep all of my client work inside a 40 hour work week, but anyone who's worked for themselves knows there's much more other work to be done too. Admin, finances, marketing, sales and content creation all take significant time, and these ended up running into evenings and weekends in April. I need to make sure these tasks are being completed within work hours rather than being squeezed around already full days.

One of my goals for this year is to release a digital product of my own too. Besides dismissing a few half-baked ideas, I didn't make any progress on this in April. I need to take concrete steps towards making a digital product a reality in May.

I also realised in April that I need some time off. The UK has been in some sort of lockdown throughout 2021 so far, and as a result there's not been too much to do other than work since November last year. This has left me feeling tired, easily distracted, and uninterested in my work. Now that the lockdown is easing slightly, and the weather is better, I think it's probably a good time for me to get away from my computer for a week and do something different.

Goals

I have 5 goals for May. All but the last item in this list are things I have direct control over, and so this should be achieveable:

1. Take a week off.
2. Write a blog post focused on product engineering.
3. Tweet every working day, trying to be insightful.
4. Put together 3 product ideas that I think could work, and analyse viability of each.
5. Generate enough revenue to cover living expenses and investment goals again.

That's all for April! You should follow me on Twitter if you want to see how this freelancing adventure develops for me. I also have a RSS feed on this site if you'd just like to keep track of new posts on this blog.

Why I'm going solo

I did a lot of introspection at the start of 2021, and decided I'd like to change my work in three big ways that weren't compatible with running an agency full time.

Control over my time

My 20s were a bit of a blur. Much of that time was spent working hard to do grown-up things like buy a house, get experience in your chosen career, and save/invest any spare money I had for the future. I did a lot outside of work too, but I was always going with the flow, rather than making deliberate decisions about how I lived.

I'm now 32, and while I love my work, I want to be more careful with how I spend my time. Going solo will give me more flexibility to arrange my work around my life, rather than my life around my work. This doesn't necessarily mean I'll work fewer hours overall, but it does mean waving goodbye to the restrictions of a standard 9 to 5.

Trying new things

Throughout my career I've found it difficult to make time to experiment with new technologies, ideas, and directions, despite having a strong desire to do so. Commitments to organisations, clients, and employees have always come first.

Going solo allows me to make quick decisions around my work and take bigger risks knowing I'm not going to impact negatively on others. If I want to spend hours a week on a digital product, I can just decide to do so. If I want to try a different approach to anything, I can just do that too.

Playing to my strengths

I like to work closely with people on code and product problems, and I'm naturally suited to long periods of singularly-focused effort. I'm good at this, and it's always made me happy, so it seems wrong not to work in this way as much as I can.

Unfortunately, running an agency demands a lot of shallow work time that just doesn't gel with my particular brain chemistry. The more Leaf grew, the more it became apparent I was heading in a direction that took me away from the work I loved.

What I'll be doing next

Consulting

From April 2021 I'll be working as a freelance development consultant with a focus on helping organisations get digital products to market. I love all the new technologies available on the web today, but I believe we've over-complicated web application development to an absurd degree as an industry. I'd like to work against that trend by helping organisations get their digital products off to the best start with solid foundations, room to scale, and costs under control.

Product development

Alongside my freelancing, I'll be taking time each week to begin building my own digital product. This will dovetail nicely in with my client work, showing I practice what I preach, but will also help contribute towards growing my streams of income over the next few years.

Writing

Lastly, I'm going to be blogging about my journey as a solo developer and consultant. I'll keep things open by sharing details on the financials of the endeavour as I go, as well as other juicy insights as I build in public.

If you'd like to follow me on my journey, I'll be sharing everything on Twitter. I also have a RSS feed on this site if you're cool like that. There'll be more tweets than blog posts, but I aim to keep it valuable and non-grifty on both fronts.

In all this time, I've learned that while incredibly powerful, doing JavaScript properly on the front end can be very expensive.

Diminishing gains

With web applications, value gained vs. money spent isn't exponential, or even linear - the gains are often diminishing. Getting from 80% valuable to 100% valuable doesn't require an extra 20% of development spend, it often requires an extra 100% or more.

Our industry is lead by hyper-profitable tech giants, for whom spending this additional money makes sense. A good example is Facebook, where React is used to build advanced front-ends, delivering maximum revenue for the company.

For Facebook, maximising revenue might mean hundreds of millions of additional dollars on their bottom line. The sheer scale of their operation means it's a no-brainer to spend the money required to go full JavaScript, handling all of the following pitfalls:

• What if the JavaScript is slow to arrive?
• What if the JavaScript doesn't load at all?
• What if the JavaScript isn't interpreted as intended by my browser?
• What if a cached version of the JavaScript is loaded that isn't compatible with a new API?
• What if the user has JavaScript disabled?
• What if the user's connection is really slow, and data requests initiated by the JavaScript fail to respond?
• What if the user is using a very underpowered device that can't handle the JavaScript?
• What if the user has a browser extension installed that interferes with the JavaScript?

A lot of us aren't like Facebook though. We work with much smaller businesses where the cost of handling JavaScript's pitfalls is proportionally much higher. The economics don't work the same way, and a JavaScript web application is comparitively expensive to implement properly. So expensive, in fact, that instead of handling the pitfalls, we often just accept that some customers will be unable to use our app.

Round trips and progressive enhancement

Most small and medium sized organisations are better off building with plain old HTML and CSS, using round trips to the server, and a sprinkling of JavaScript that progressively enhances a solid, economical foundation.

This old-school approach yields a nice binary page load; either the HTML loads and can be interacted with, or it doesn't and can't. Rather than having to negotiate JavaScript's pitfalls, this approach makes it cheap to build a working web application for all of your users - users who you can bet will have lower-powered devices, on slower connections, running older software than your development team.

In the vast majority of cases the quality of the web application doesn't suffer from this approach, it gets better instead. Pages still load quickly, elements are still styled nicely, and JavaScript is still there doing its thing. The only difference is you're building from stable foundations by default, and putting in the extra time to progressively enhance where it makes sense.

Keeping JavaScript in its place

This isn't to say single page JavaScript web applications never make sense, because they sometimes do. It's just that most web applications being built today are simply user interfaces that store and retrieve information from a database. They're not putting a dent in the universe, but they do need to deliver value in organisations where a developer's salary is a pretty significant source of cost.

We developers need to be more cognizant of the economics of our work, and build our apps accordingly. Most development teams starting JavaScript web applications today won't consider the pitfalls listed above at all. They'll just start building, and assume their experience is everyone else's experience too. As a result, some of their customers won't get to use their application, and their business misses out. I am definitely guilty of making this mistake.

So, next time you're building a new web application, consider the economics of your approach and then proceed accordingly. More often than not, you'll find you can create a high quality production-ready product using just HTML & CSS. From there you can progressively enhance with something like React where there's clear value in doing so, safe in the knowledge you're not going to be turning customers away, or spending more of your company's money than necessary to deliver a great product.

However, most of us fail to take action on longer term opportunities for wealth creation. We pay compounding interest on bad debt, our savings get eroded by inflation, and we purchase liabilities rather than assets.

We mean well, but we struggle to save $100 per month while missing opportunities that could grow to $1,000,000 over a lifetime. We fix the wrong problems.

The wrong problems in code

As developers, we tend to fix the wrong problems in our code too. Take the following basic example:

This function returns true if each number in a given array increments by one from the number that preceeded it (e.g. 1, 2, 3), and false if not (e.g. 1, 3, 2). It's a little verbose, but with 15 minutes of refactoring we could transform it into something more clear and concise.

If we did refactor for clarity and brevity, it'd be tempting to think we'd spent our time well. However, taking into account the wider context of a whole codebase, we'd see the biggest issue isn't how the function is written, it's actually the function name. getsBigger is both misleading and ambiguous.

Any developer seeing getsBigger in use is likely to mininterpret its operation from its name alone. This wastes time, reduces the readability of the codebase, and increases the likelihood of accidental bugs through misuse. By contrast, the code within getsBigger is actually a non-issue. It works, it's reasonably efficient, and it's unlikely to need to change.

Most developers will opt to rewrite the function, but the best value improvement we could make to getsBigger would probably be to rename it to clearly convey its purpose. Something as quick as a find and replace across the codebase would mean every future developer could confidently use the function without needing to see how it's implemented. We'd be making a small change that pays off big over the long term, and we'd be fixing the right problem.

This is not laziness! Refactoring without considering value is the lazy way to go. Taking time to think about improvements that deliver long term compounding benefits takes effort, and the right refactor to make isn't always the obvious or large one.

Software development is very expensive. As an industry, we need to be better at recognising this, and making pragmatic tradeoffs between time invested, and value delivered. We need to resist the vanity improvements, and look at the larger context to see where the value lies.

How to choose what to refactor

How best to improve a codebase is highly subjective, but I've found a good way to keep myself improving the right things is to regularly ask myself these sorts of questions:

• How does this software affect the bottom line of the business?
• What's the roadmap for this software?
• How will the demands on this software change?
• How will the number of people using this software change?
• Based on its current trajectory, what will this codebase be like in 6, 12, and 24 months time?
• Which parts of this codebase churn, and which don't?
• What's the development team like that work on this project?
• What aspects of this codebase make it difficult to get work shipped?
• What parts of this codebase confuse developers?
• Which parts of this codebase require esoteric knowledge?

Thinking about these for your own work will help you identify better refactors to make, and more effectively fight the never-ending battle against pernicious technical debt on your software projects. Good luck, and happy refactoring!

Twitter feeds me a constant highight reel of work and life achievements. New code library releases, new app releases, new product features, new blog posts, new videos, new interviews, and most frequently of all - hot new takes.

When you've spent the entire week solving problems that aren't world changing, Twitter can leave you feeling like you've achieved nothing at all. The sad part is, this can even happen when you know you've done lots of valuable work.

Not talented enough

The basic premise of Twitter is that you follow people you're interested in, and share content you think others might find interesting. This can create a healthy platform for learning, socialising, and sharing your work.

However, if like me, you use Twitter to follow the best and brightest in your industry, your perspective quickly becomes skewed towards feeling distinctly average about yourself. It's very easy for this to happen when your view of your industry is the content shared from the top 1% of talent on the planet.

Not social enough

Twitter makes me feel like a shy kid at a party. I'm constantly wanting to say things, but I don't in case something bad happens. What if I've misunderstood something? What if people don't find my joke funny? What if nobody cares about the thing I think is cool? Worst of all, what if I accidentally say something un-woke and have my career ruined over a misunderstanding?

Twitter rewards confidence, extroversion, clear communicators, and quick-wittedness. If you're none of these things, using Twitter can actually be a tiring, even emotionally draining experience. You feel bad about not Tweeting enough, feel bad about Tweeting and getting no engagement, or feel bad when someone takes something you've said the wrong way.

What can I do about this?

Despite everything I've said above. I actually enjoy using Twitter on the whole. It feels like the right format for a social network to me. I also believe that as a company owner, having some sort of social media presence is important.

When I really get introspective, I also realise the issues I've highlighted aren't actually problems with Twitter at all. What I'm experiencing are my own insecurities, Twitter is just surfacing them. In response, I've decided to remind myself of the following when using Twitter.

Comparison is the thief of joy

The only person I should be comparing myself to is my past self. Also, I need to remember that I've chosen to follow high achievers on Twitter because I want to learn and improve. I shouldn't feel bad that they're outperforming me.

Work doesn't need to be shared to be valuable

Some of the most valuable work I've done in my career is unbelieveably mundane. I should seek a sense of achievement from working on projects I care about, and not feel I have to make a show of things to be worthwhile.

Stop worrying so much about what people think

People will disagree with me, that's fine. People won't find what I have to share interesting, that's fine too. Nobody is dwelling on my Twitter activity, or lack thereof, I shouldn't either.

Nobody can define success for you

Success isn't money in the bank, code written, content shared, a follower count, travelling for conferences, or hours worked per week. Success is achieving what I set out to do, nothing more, nothing less.

You'll find yourself needing to know a little on a broad range of subjects like finance, marketing, sales, management, business, economics, and law. You can learn these on an ad-hoc basis, but it's a time consuming process.

Podcasts and audiobooks are very helpful for building this knowledge. They allow dog walks, gym sessions, or long drives to double up as learning opportunities.

Sell your head

Some clients see you as a pair of hands, there to implement their ideas. Others will see you as a true expert in your field, there to guide their thinking.

Selling your expertise is where your true value lies, but it's hard to do if you're not seen as an expert from the beginning. Establish an expert position early on in each client relationship, and make sure your value is driven primarily from your ideas.

Work is not your product

Your agency may spend a lot of time writing code, but you're not paid for code. You may even build beautiful software products, but you're not paid for software either.

You are paid for delivering a desired outcome for each client you work with. Make sure there's no confusion about what this outcome is, keep it front and centre, and let it guide your decision making.

Value is subjective

The exact same work may worth £5,000, and £50,000 to two different clients. Take steps to figure out what value you're delivering, and charge an amount that keeps the exchange worthwhile for both parties.

This isn't greed, it's professionalism. By ensuring everyone involved benefits from a good work, you incentivise everyone to work together efficiently, effectively, and to the best of their ability.

People skills matter

You probably decided to start a business because you posess a set of valuable technical skills that you thought could be better put to use if you were your own boss.

While your technical knowledge is key, actually getting the opportunity to use it to deliver successful change to your clients will depend on your ability to understand, emphathise, translate, explain, teach, and lead.

Don't underestimate ths importance of developing these softer skills. Most technical employees are very shielded from the people side of the organisation they work in. As your own boss, you won't be.

Keep marketing

When you're busy, marketing can feel a bit like handing out flyers for a sold out gig. However, being constantly a little oversubscribed provides income stability, keeps you aware of new opportunities, increases the amount you can charge for your work, and lets you choose who to work with.

A good marketing funnel takes time to develop. You don't want to be scrambling to build one once you're already in a quiet period. Make time for marketing from the beginning, and improve as you go.

Pick a niche

You're probably able to use your skills to solve a broad range of problems for clients reasonably well. Unfortunately, so can loads of people.

Aim to be one of a few businesses with true expertise in doing what you do. This will make you an obvious choice for anyone looking for help with your niche. You'll also likely be solving the similar problems for each new client you work with, perpetuating a virtuous cycle of learning, experience, efficiency, and expertise.

Size matters

For an engagement with a lot of implementation work, clients will sometimes choose a larger, technically mediocre agency over your smaller technically brilliant one. This will seem like a lack of confidence in your technical abilities, but it's not.

From a business point of view, the deep bench and established nature of a larger agency just make them a safer bet when there's a lot of implementation work to be done.

When you're starting out, you can make yourself more attractive by building a bench of your own, developing specific expertise that makes you the obvious choice in spite of your size, and selling your knowledge rather than your implementation.

Build some runway

When you land your first big client, it can be tempting to feel like you've made it, and start spending. Resist this urge.

Before you're established, losing a client or having unexpected costs to deal with can easily topple your business. Having several months of payroll in the bank will give you room to manoeuvre, and peace of mind to make clear-headed decisions about how to move forward.

When you have employees, cash becomes even more important. Don't rely on luck. Know your burn rate, and give yourself a generous runway.

You can fire your clients

Sometimes a client relationship will degrade to the point of being unsalvageable. In those cases it can be appropriate to fire your client, and it's sometimes the best way forward for everyone involved.

A firing needn't be abrupt. You can wind things down over a month or two for a clean and easy break, or seamlessly transition the client over to someone else who's a better fit for their needs.

Grow without hiring

Hiring is not the only way to grow your business. You can stay physically small, but do more valuable work with larger clients as your expertise develops. Alternatively, you can build a bench freelancers while keeping your core team small, like a tap of expertise you can turn on or off as required.

At Leaf, we've found a mix of hiring, and working with known and trusted freelance subject matter experts has helped to smooth out heavy workloads, and improved the quality of our output.

Anything can be a mentor

Mentorship will be incredibly valuable for helping you learn and make good decisions, but it doesn't need to be a one-on-one activity, or even come from a person.

A relevant blog post, podcast, audiobook, presentation, or online discussion group can all be forms of mentorship. Don't feel like if you're not constantly able to travel meet people you can't be mentored.

You can't outwork busy

If you've got too much on your plate, you need to work less, not more, to get on top of it. Trying to outwork busy doesn't work, because if you're doing your job right, each piece of work will result in even more work being offered back to you in return.

Like a throttle on a car, your pace of work needs to be consciously controlled to avoid a runaway acceleration and you repeatedly butting up against your physical and mental limits.

Remain dispassionate

Too much passion for your business will make your life an unbearable emotional rollercoaster. Your business isn't a success if it's making you miserable, and a lot of what happens will be outside of your circle of direct control.

From a certain perspective, your business is just a game. Treat it as such. Do your best, but don't expect to win every time, and don't get too emotionally invested.