Starting Up: My learnings from failure to launch

In March of 2020, the world went into lockdown. As a result, my world changed permanently. For the best part of 4 years, I'd worked as a maths tutor. I love teaching mathematics, I love teaching in general. There are few things I've found more rewarding than helping young adults achieve their ambitions in their exams and then getting to see them go on and pursue incredible degrees and careers. Obviously, with the world shut down, tutors became pretty redundant. I also wasn't eligible for self-employment grants because tutoring only made up 40% of my income, not the 50% required to qualify. Fortunately, that year my costs dropped considerably.

About two weeks into the pandemic, I was working on a project called Green's RPG and I was thinking about this problem I'd been throwing back and forth for a while. Teaching maths, particularly Secondary (High) school maths involves a lot of standardised testing. In England and Wales, that takes the form of GCSEs and A-levels (Standards and Highers respectively in Scotland). As a tutor, you're usually vying for past exam paper resources with the schools. It's not their fault, there's a good reason for practicing with past paper material, exam practice is essential.

At this point, I can imagine the Greek chorus of people going "schools just make you good at test-taking". That's categorically, and unequivocally untrue. Maths exams, for all their convolution, do imbue important and oft-overlooked skills. Communication, time management, and utility motivation. People who see exams as "just tests" fail to understand that the exam is a puzzle in its own right. The exam is symbolic of reality. You can build a really good product, based on really clever maths (or science, or history, or whatever other subject you choose), but ultimately, most products are 90% delivery. The same is true for an exam, it's not about what you're saying, it's about how you say it.

That said - and for a measure of balance because ultimately this article is about failure - passing isn't everything. Succeeding, or getting the best grade should not be the sole measure of an individual's self-worth. Those who excel at exams deserve to be lauded, but that should not be at the expense of those who fail. Similarly, those who fail shouldn't be consoled with the notion that exams are ultimately meaningless; to do so only denigrates the achievement of others, and does not, in fact, do anything to contribute to the self-worth of those who do fail.

So, I believe in exams. I believe they're a necessary evil of pedagogy. I believe that their value is over-estimated by some and under-estimated by others. The question I wanted to answer though was: can AI write one? The answer to that I still believe is an emphatic "yes". Exams aren't as easy to replicate as they may appear. It's not a simple whack-some-random-numbers-in-and-off-you-go situation. Exams - particularly GCSEs and A-levels - are riddle with subtle semiotics, a myriad of question types balanced against a specification, and strict rules guiding the numeracy range that should be tested.

For example, "Write 4+5" means something different to "Work out 4+5" in GCSE speak. "Write" means the answers are already on the page, or have already been worked out you just have to write it, "Work out" means you have to calculate it. These are subtleties that make encoding a model for writing just maths exams alone an interesting idea.

So, I built it. I built an AI tool capable of generating representative GCSE maths papers. It took a weekend, and I wrote just shy of 200,000 lines of Python in a 40-hour programming binge*. And so Tryal.AI was born.

(*I know this isn't healthy, and the differences between being 22 and being 25 are stark)

This is where our story really starts

This is where our story really starts. Up until this point I hadn't built this tool with the intention of selling it. I wasn't averse to it, selling just wasn't something I'd considered. I pitched it to a friend of mine, who I'll call F (I'm sure they'll read this and say it's fine to use their name, I'm just too lazy to ask). F looked at it and suggested we launch it as a web app, on a subscription basis, think Netflix for exam papers.

"Your product itself is rarely where you'll spend most of your development time (and consequently money)"

Developing the web platform took two months, accounts, billing, hosting, integration, design, you name it. I was (am) a developer too. I wasn't learning loads of new skills to build it, 2 months is just the nature of the beast. This is my first learning. Your product itself is rarely where you'll spend most of your business development time (and consequently money). There are of course exceptions to this rule, but it's very unlikely you're one of them.

This brings me onto one of the first bits of advice I give clients working on a budget (and naturally most clients are working on a budget). Do you really need it? The web is a hard place to succeed, it's not a build-it-and-they-will-come situation. Chop your product back and fit it into your business strategy. Every feature or aspect you specify when asking for something to be built should have a definitive answer to the question "Why does this need to be in the product for my product to work?".

As a developer, I can tell you, there are answers to that question that will shock you. It's my firm belief as a small business you don't need a billing system. You don't even necessarily need an accounts system. You might be thinking this sounds crazy but it's simply not. If you have a UK bank account, or Paypal, you can easily accept card and bank transfer payments, you have a developer build 30-day rolling passwords, and every time a subscription is taken out or renewed, you send out that day's rolling password. It's a hack. I know it's a hack. But, here's why you should do it.

• Account systems are expensive. Not necessarily to maintain but definitely to build. And to build properly. If you have user accounts, you're in the tech game, and you're also in the data protection game. Rolling passwords contain no user compromising data. You can keep records of email addresses offline on a spreadsheet, or on a cloud-hosted CRM.
• Billing systems are expensive. Again, not necessarily to maintain but definitely to build.
• You don't have any customers. A billing and accounts system sets you up for a scale that you're simply not operating at yet. If you launch and get a thousand customers, you've now got the money to pay for an accounts system. If you launch and the first bit of feedback you get is, "we want an accounts system", then you can still add an accounts system later. You can't unspend the money you've spent.

This is just one example of working leaner. Thinking about what it'll actually take to capture your first £1.

"The sooner you show it to people, the sooner you'll figure out what's wrong with it"

So we spent two months in development, and in that time, we did get things right. This isn't just a story of a failed startup dream where we did everything wrong. One of the things I'm most proud of is getting out in front of people and showing them Tryal.AI as we were building it. The sooner you show it to people, the sooner you'll figure out what's wrong with it. Don't delude yourself, you've not come up with the perfect product the first time. That's not to say that the core of your product is bad, but - as I've said before - delivery is 90% (maybe more).

When I build (and I strongly encourage you to find a contract developer that does this) I deploy as soon as something is ready. Even as a contractor, I like to put the stuff I've been asked to build in front of people as soon as possible. It makes it easier for you to know if changes are going to be needed before I move on to the next feature. More importantly, it gives clients the ability to put it in front of their potential customers. There's nothing wrong with putting an unfinished product out. There is no amount of polish, tweaking and changing that you can do to make something right the first time. Instead, you'll burn through your time with your contractor. It's not their baby, it's yours. You'll be forced to put an unfinished product out anyway, but, without the ability to provide feedback directly from your audience as it's being built.

"If you are launching some sort of technical offering, you need to not only think about the cost of building, but the cost of maintaining it"

I'm going to circle back to the start, and talk about F a bit more. I did approach F for a reason. They've built startups before and they have a degree of business acumen that I thought I lacked. By hiring a contractor, you're saying that your team (even if that's a team of one) lacks the skills to complete the product. If you're not a coder yourself, that may well be true. But a contractor is ultimately a temporary patch, to a long term problem. If you are launching some sort of technical offering, you need to not only think about the cost of building, but the cost of maintaining it.

I have never worked for sweat equity. I'm not 100% against it, but most contractors are. What you need to work out in your business, is how you fit into the equation. In Tryal.AI I was two things:

• The domain expert; I knew about exams, I knew about their intricacies, and how they're written
• The developer; I knew how to build a platform and how to deploy one

But I was not a salesperson, I was not a marketing person. I tried to be that person and had some minor success signing people up and getting subscriptions, but I was not a salesperson. If you go down the route of hiring a contractor, the obvious benefit is retaining a stake and it remaining your business. The cost is a temporary, more expensive person to fill that role. These are the kinds of Faustian bargains we make in order to build a startup.

This point all wraps back into my first point, the more you spend on building, the less cash you have remaining for everything else - especially maintaining. The web, mobile, you name it, it's not a static ecosystem. It moves, it changes, things become obsolete and they break. No contractor can be held be responsible for that which in any other product would have a well-known name - "wear and tear".

"Building your product, should come after you've developed a route to market"

Staying in development is really costly, especially if you're not garnering feedback. But even if you are, you've probably come to the conclusion you can't charge for the product yet so you're giving it away. In doing so, you're hampering your ability to grow and improve it. The beauty of web and mobile apps is that - whether it's for 1, 10, 100 or 1000 people - a product improved once, improves it for everyone. This is why building your product, should come after you've developed a route to market.

Feedback will change your product, and might even tweak your route to market, but it's unlikely that feedback will completely change your route to market. Hence, it's good to work out a route to market before you build your product. More than that, even if feedback does change your route to market, that's the point of feedback, to invalidate bad ideas, and validate good ones.

Summary

There's an idea that runs throughout the startup world that you should "fail fast and fail often". I think it's bulls#@!. I think it's a saying that creates the kind of VC startup graveyards you'll find if you just dig into the 1,000s that fail hard. But, like most sayings, there's a kernel of truth beneath it. Failure isn't a bad thing, and you'll fail faster, and more often with all this advice. But, you'll fail softer.

Finally, I offer one last drop of wisdom, that was passed on to me by my father. Something profound that stuck with me from the first time he said it.

"There's no point working for yourself making the same or less money you could make working for somebody else"