10 things I learned attempting my own startup
I’ve had a lot of fun building featureflag.tech over these last few years, and while I’m sad it hasn’t worked out I have gained a load of new experiences I wouldn’t have got working at my day job (engineering manager).
There’s been some tough lessons from a business perspective, but on a more positive note I’ve gained experience with a tonne of fun tech.
Here are the top 10 things I learned when attempting my own startup.
1) Building an audience is hard
The first thing we did once we had the idea for featureflag.tech was to build a marketing site to try to gauge interest. After 2,000 visits over a number of months we were averaging 2% to 3% sign up to our “early access beta” mailing list. We thought this was a good enough signal so we went ahead and built our MVP.
However since launching our MVP the signups have been much lower, and although we have had users take the ultimate step: trusting us by entering in their credit card details, relying only on SEO just isn’t going to bring users in fast enough to make this a worthwhile endeavour.
Our initial plan to rely on SEO and be the best tool people can find now feels very naive. We live in an attention economy, where you are competing for peoples time, where because there is so much content on the internet users make decisions in seconds knowing there is a Google search page of alternatives a click away. We could build the best product ever, but that isn’t going to make people come to your website.
We’ve been given advice that we need to actively seek out potential audiences and go sell to them. While we think this is the next natural step, none of us are sales people and we’ve not enjoyed the experience so far. We are definitely builders — product and engineering folk.
The next time we attempt another startup we will probably start at this step. But to do this we’ll need a founder who can do sales and marketing.
2) Bots play a much larger role on the Internet than you realise
It’s depressing to say but we’ve come to the conclusion that SEO, Google ads and analytics are potentially a fool’s gold due to the overwhelming amount of bots that have flooded our data. Well over 75% of all our stats are due to bot traffic, it’s disheartening to work this out only after we built our MVP.
While we can’t prove it, our hunch is that most of the traffic coming from Google Ads are bots, and I’m certain most downloads of our client libraries from NPM and Pypi are bots too.
When you stop believing your own analytics, it becomes hard to create funnels or trust any dashboards.
3) No one wants a beta product
Our first MVP was free to access. We didn’t require you to enter your credit card details and we were wanting to let people use the product for free. We labeled it as a “beta” release. Barely anybody signed up.
Getting feedback from people was hard, but the feedback we got was “I don’t want to beta test your product for you”.
So we realised people want confidence in your product. It was only after we removed the “beta” sign and asked for credit card details that people started to sign up.
4) Our social network was better and more trustworthy than paid for professional services
Lots of my friends helped us with problem interviewing and user acceptance testing. We’ll always be grateful for the time people gave us. Someone even wrote the initial version of the Python client for free for me. Friends are great!
But we also got burnt pretty badly when the graphic designer we sourced from fiverr only delivered 1/3 of the agreed brief after fiver decided to take the full amount of the agreed fee from my account without asking. The designer decided they didn’t need to provide the rest.
We got more value from the goodwill of people we knew rather than paid professionals. I’m also never going to use fiverr ever again.
5) PreactJS is a great, lightweight alternative to ReactJS
I’ve built a fully working CRUD UI in PreactJS (including tests!). After moving into management for my day job I’ve always been conscious that I’m losing touch with my frontend development.
I’ve felt like a dinosaur when talking to newer frontend devs: they seem to care less about HTML/CSS and performance but really care about build tool chains and ReactJS.
I’ve always been a bit suspicious of ReactJS, but when I found out about PreactJS (3Kb alternative to ReactJS) I built the first version of the UI with it and never looked back.
I’m definitely a PreactJS fan and am proud that the major frontend application that powers featureflag.tech not only supports IE11 but comes in under 200Kb.
While I’m not a WebPack expert, I did create my own build tool chain for PreactJS so feel like its a tool I’m finally comfortable with.
6) It is possible to build an entire startup based on serverless technologies
One of the core objectives for us was to keep costs to an absolute minimum, not just because we wanted featureflag.tech to be the most affordable option but because we bootstrapped the entire endeavour ourselves.
So from the very beginning my plan was to build as much of featureflag.tech serverlessly as possible. Apart from the subnets that the VPC is based on, everything uses a serverless technology. These are all the AWS based services I used:
- Network: Cloudfront and ALB
- Compute: Lambda
- Data layer: S3, RDS Aurora Serverless and Dynamo
- User management: Cognito
- Operations: CloudWatch and AWS Grafana
- Email: SMS
The biggest benefit of all this has been how robust and reliable the infrastructure has been. It’s never gone down once and it scales out effortlessly. The only way this can go down is if I make a mistake when deploying new versions.
7) The serverless.com framework is great for managing AWS Lambda based software development
I have developed the Lambda based parts of featureflag.tech using the Serverless framework. 3 top features of it:
- It provides a nice developer experience. The config file that powers everything is a nice abstraction on top of Cloudformation, while also allowing you to easily add in additional none Lambda infrastructure. Running everything locally is super easy too. Something we’ve not been able to do with Terraform at my day job.
- There are a tonne of community written plugins that let you extend it. Ones I’ve used are S3 deploy, local HTTPS development and optimised source maps. I even wrote my own to allow you to do local development with an AWS ALB.
- It’s easy to integrate with environment variables, and so building serverless applications using the 12 factor app process is possible with this framework.
8) Github Actions are great and getting better
Github Actions came along just as I started needing better deployments and stopped me from migrating over to Gitlab (it’s CI features are really good).
While the featureflag.tech codebase was a single repo, using the monorepo pattern we were able to deploy several pipelines from it with Github Actions. Doing this was surprisingly easy and is a great feature of Github Actions.
The main drawback of Github Actions is the lack of a manual button in the UI to run gated steps in your pipe. However I was able to get round this and when I deploy into master my test env is built automatically. Once I’m happy with the test env I go into the Github Actions UI and manually kick start the deployment to prod.
9) Stripe integration is hard but so useful
We used stripe.com as a payment provider. To do this we had to integrate stripe.com into our PreactJS frontend. This was so much more complicated than I had thought it would be, especially with having to consider all the non happy paths that can happen with payments.
I now understand how much risk you expose yourself to when setting yourself up to take online payments, and I can understand why SaaS prices are higher than I used to expect them to be.
10) I don’t want to be a solo start up founder
At the beginning of this I had the idea of being a solo founder with a regular income on the side that I could maintain in the evenings and weekends. Along the way I picked up a co-worker in my wife who started helping with the business analysis (she did all the Stripe investigation work), testing, UX interviewing and small technical changes.
Since this experience my wife has now got a job as a software engineer. This has been the biggest surprise out of it all. Watching her confidence grow as she did more technical jobs for me, and then deciding she wanted to do it full time.
I’ve also learned that I don’t really want to be a solo founder. While I’d still be interested in working on a start up in the future, I now realise that what I really want is to work on just one thing with a team of good people and work towards making that as great as possible. I don’t care if I own it, I just want to build something cool that people find useful.