I have been working in software for almost 9 years now.

And in that time, I've gotten to do a lot of cool things:

• Me and Alexander Selling started iControl and grew it to a team of 12 people spread across 2 continents, serving some of the largest construction companies in Europe with our solution, despite being first-time founders without much of a clue.
  

• Growing iControl to around $50K MRR before taking any investor capital, by executing our outbound sales process and navigating the complicated decision structures in construction companies.
  

• Won a pitch contest that got us invited to Germany where we met 500 Startups and later got accepted, where I had to move from Sweden to San Francisco with 10 days' notice.
  

• Pivoted away from building a niche construction app and gave our best shot at solving the significant problems facing the construction industry with next-generation ERP system, really swinging for the fences when it comes to vision.

  Me pitching at the 500 Startups Batch 19 Demo Day in 2016 - Mountain View, CA:

There isn't much I would change about our journey. After all, it's these experiences that have shaped me as a founder and CEO.

I wouldn't be CEO at Heads today without them.

But if I could go back, here are a few of the mistakes I made early on—and what I would have done differently:

1. Not identifying bad product-market fit

In 2014 -Both me and my cofounder were first-time founders without any SaaS experience prior.
We had no baseline expectation of what anything "should be like".
So we didn't initially react to red flags such as:

• High natural churn - when the construction project is over, they no longer needed the app.

• Low budget given the sales process required to close deals.

• Mismatch between our app value-add and the business model of the purchasing company (on a company level, the app was loved by the construction projects)

We just took responsibility and figured these red flags were due to a lack of features, bad salesmanship or just not enough effort on our end.

Today I'd establish key milestones on a business model level.
Using those confirm that the business model of the product works, and if it doesn't - not move forward with that same idea.

2. Being in such a rush to hire.

When we started, we didn't know anyone in the software industry, except our own friends. Over time, we build a team of our friends as well as acquaintances who later became friends, and it's been truly amazing to see that team move on to new challenges at really awesome companies.

But since we always figured we weren't performing well enough, we were always playing catch-up to the growth we wanted, this meant that as soon as we could maybe support another person on payroll, we hired them.

Building up a decent cash reserve? Keeping a healthy profit margin?
We did none of that.
We hired to the point that if we didn't hit sales records, our team wouldn't be paid their salaries on time, and of course, we didn't always hit sales records.
Now I would be in less of a rush to hire new people.
Instead hiring when our work-burden and profit really warranted it, keeping a stable cash reserve.
Even then only hiring when we feel we could get great talent onto our team.

3. Not thinking of the whole product early.

We just threw ourselves into construction, an area where we completely lacked any personal experience.
I personally visited hundreds of construction sites.

We hoped to find a silver bullet use case, some core construction process that we could support – this was a red herring.

If I'd do it again - I would still focus on learning construction and visiting as many sites as possible.
But my viewpoint when doing so would be different.
I would be looking at these processes in broad terms, and try to build our product at a higher level of abstraction, trying to see the commonalities in the processes, and building on that level.

4. Not testing product ideas with MVPs

When we finally did think of the whole product.
We had a great idea, and it covered a ton of use-cases.

But we fell into the classic trap of building a "version 2".
We expanded the scope over time and didn't separate enabling technologies and features, so we had to rebuild large parts several times due to misunderstandings and bad choices in the underlying technologies.

The work took us two whole years, during which time our live product got less love than it deserved.
Given our situation - it was a complete miracle we didn't go bankrupt.

Could we have built an MVP with little perceived downsides in 2 months? Yes.

Could we have built it with a small part of our team, focusing on enabling technologies separately from features, and not losing focus on the live product? Yes

Could we have launched this version 2 feature by feature, looking at each use-case of the product, and supporting one at a time? Yes.

I'd do all of the above today.