[antfie]

My first time round was a year spent building prototypes which soon I realised was something I was doing because the non-tech part of starting up was so frightening and alien to someone who has been behind a keyboard their whole life.

The idea was simple: scheduling meetings is a pain, shouldn't this be simple by now. E.g. I don't care when or where I just want to meet with Susan tomorrow for 15 mins. You're my Corporate calendar and you know both our availability. Go figure, I'm busy. It was a search engine of sorts for meetings: "Susan tomorrow 15 mins".

Whilst this solution never intended to replace existing calendering or email, etc and just serve as a front-end, I came to the conclusion that companies already have solutions to booking meetings. The existing system works so why pay more. My USP was in time savings made => less cost. I gotta say in writing this it's making me think perhaps there is still something here I should pursue.. and I later found out another company was doing something similar after I shelved this.

I knew from day 1 I should have been validating my idea but it was so much easier to build stuff. I learnt a lot from failing this way: 1) You may have solved a problem, but it could be insignificant to the target market. 2) You have to listen to people and build meaningful human relationships in order to be successful. 3) Find someone else's problem to solve and you're likely to be on to something. 4) Fail fast, learn more

I just launched https://conciergeapp.uk on the August 5th, after a month of development and then spent a week feeling miserable because nobody will sign up or reply to emails. It's a simple tool for facilities to take utility meter readings in private residential apartment blocks. This tool notifies the residents of their readings, as they cannot get to the meters themselves in order to tell their energy suppliers. As a resident it's certainly useful for me.

This is potentially another failed product because it's not important for facilities management. it's a great tool but it doesn't solve any of their main problems. This all came about because of a conversation in which I got excited about something and then engineered a solution for a non-existent problem. I should have prodded some more to find the real pains.

In the space of 1 month and a week I find myself failing again, but this time I failed much faster and have learnt the following: 1) Find the right problem to solve and validate it before you write a single line of code. 2) Listen more. 3) Get up-front financial commitment prior to writing a single line of code