· business · 5 min read

Startup tips

Bite-sized pieces about building products - stuff I learned along the way. There are many great books that go much deeper into pricing, market fit etc.

Bite-sized pieces about building products - stuff I learned along the way. There are many great books that go much deeper into pricing, market fit etc.

The right market

Many startups target sole traders or micro businesses - and fail. Micro businesses are a hard market. They often lack the motivation or skill to grow - that’s why they are micro.

A huge addressable market looks great on a presentation but, a small market of switched-on enthusiasts is much easier to deal with.

The absurd fact about pricing

You will get more customers if your product is cheaper, right? Probably… but while your total customer count might be higher, you could end up with less good customers overall.

If your product looks too cheap, some customers won’t take you seriously. Then, there are paying customers you don’t want: Customers that hog the Support Team with silly requests. Customers that overuse uncapped resources. Customers that are notoriously late with payment. Customers that ignore security guidelines. Customers who will forever stay on the free plan.

Getting pricing right is tricky and many founders start too cheap.

Products (mostly) don’t sell themselves

Internet is full of stories about the viral success of startups. Realistically, viral success is as common as diamonds. Most good startup ideas require a huge, sustained selling & marketing effort. Established brand, customer recommendations and good SEO will eventually have a significant impact but it can take years. And, the impact of a good SEO is not what it used to be, as the first page of Google is full of paid links. It’ll be interesting to see how will the AI revolution impact this further.

Selling is a sophisticated skill that many tech founders underestimate.

Skills to tick

Possibly the hardest part about startups is that you can get many things right and one thing wrong, and it’s a fail. Question your team’s skills and limits. If you are lacking an expertise, it’s often best to find a professional who can cover it. It could be a someone with a full time job in the field, looking for an extra challenge on the side. Trying to learn a new major skill like marketing, sales or finance could be too much of a distraction for a founder.

This is connected to the ideal founding team size. More founders means higher chance of disagreements but as well more skills covered. What is the right tradeoff… depends.

Startup risks

There are much more likely to succeed, less stressful paths to a comfortable financial position… like finding a well paying job, living on a budget, and investing savings into property.

It’s exciting though to aim for the stars and to live a dream.

Some startup ideas aim higher than others and some are less risky. There are various approaches to analyzing and rating a business model, like Lean Canvas. Pick a few ways to validate an idea and don’t take shortcuts - when you are looking for 10 people who will commit to buying your product once ready, don’t stop looking at 5.

It’s easy to fall in the trap of speaking with a few enthusiastic potential customers… but then, when the time comes to buy your product, they suddenly won’t follow through. People will often play along when interviewed - it feels nice to agree. Rather than asking for confirmation of your ideas, ask simple questions such as ‘Why?’ and listen.

Validating an idea is not selling.

Business dependencies

You have a brilliant startup idea. You execute flawlessly. People love it. But then, another company you product relies on fails you 🫠. Avoiding hard dependencies is a no-brainer but it’s often not possible. Does your product rely on a single API, or a single agreement? Is there a way to build a redundancy or a failover? Is the dependency risk so high it’s not worth proceeding?

Raising money

The typical startup journey is described as raising a Pre-seed, Seed, Series A/B/C/D rounds, followed by an IPO. Then credits roll and everyone celebrates.

In reality, it might not be in the best interest of the founders to raise every single round that ever got named. Raising takes time and effort. Whoever is raising (the CEO, typically) will likely not have the capacity to work on other things well.

Having certain shareholders can be an asset, but some can be trouble even if they are nice people. Some legal actions require notification of all shareholders - good luck chasing that dude on holidays in Thailand, who invested $5k 6 years ago and doesn’t remember who you are anymore.

  • Some very successful startups (like the creators of Basecamp) never raised external funds. They followed the old fasioned way from times before angels and VCs were a thing: Save some money, build an MVP, charge for it, work on growing the MRR (Monthly Recurring Revenue), hire when you can afford more staff.
  • If you want to go faster, consider getting a business loan or raising more money from cofounders. Has everyone maxed out their mortgage and credit cards already?
  • Give generous options to your staff. Some might even agree to work for equity only, for some time on a casual basis.
  • Lastly, raise one of the traditional rounds but be thrifty with the money - make it last longer.

Ideal team size

Budgetly, consists of a financial webapp, mobile app, transaction authorisation service, accounting integration, backoffice and more. It’s basically a little bank. Most of it was built by 2 developers (me being one of them). Only after we had significant traction the team grew. I wish we grew faster but somehow many customers say that our product is better that those of our much larger competitors.

The point is that a single developer can get a lot done - in the right environment. Ultimately as a team grows, the less output will each new engineer add. Based on what I’ve seen, the maximum reasonable number of engineers working on one codebase is about 3 to 15 - it varies greatly depending on code structure - how many tasks can be worked on in paralel, without a “merge hell”.

And, here we come to the number one benefit of (micro)service oriented architecture over a monolith - more engineers can work on it efficiently. I’ll write more about that later :)

Share:
Back to Blog

Related Posts

View All Posts »