How We Built Haboo in Under One Year

In May 2025, Haboo Money launched their Production v1 iOS app, resplendent with scalable AWS Serverless backend and fully integrated virtual banking payments.

Barely one year before that, the company had been just a collection of ambitious Figma designs and a burning ambition to help everyday people out of the Debt Trap.

How did we get from Zero to One so quickly? Here are some key behaviours which kept us on the track to that success.

Always Be Delivering

This is probably the single most important principle of our approach: Put a Product in the Founders’ Hands right away - and keep doing that.

Every beautiful product involves not only great, intuitive design BUT ALSO has been on an evolution based heavily on the reactions and feelings when able to see and use it.

It’s therefore imperative that your entire technical culture is geared towards full-stack delivery of the primary product - in our case, an iPhone app - from the very outset.

To begin with this will be a very small and flimsy offering - in our case, basically just the ability to log in and have the app say “Hello, Mark!” but even that gets the creative and usability wheels turning in everyone’s heads, from the very start. Utterly invaluable.

Face Your Demons First

In the words of the great Marty Cagan, it’s crucial to “tackle the big risks early” and remove as much uncertainty as you can before any significant investment of effort or capital has gone into the idea.

It’s too easy in a Startup to create darlings of certain features, or to get unhealthily wedded to the USPs too early - Before you can lean into these things you must force the earliest builds to tackle some of the Big Questions first.

These ought to include value and usability hypotheses, centering around the likelihood that users will want to operate the product and will be able to understand it, as well as feasibility hypotheses, which are largely concerned with build and integration questions.

For example, one of our biggest questions at the start of Haboo was: Can we utilise the emergent Open Banking VRP (Variable Recurring Payments) model to automate loan repayments to virtual bank accounts, in a way that will operate at scale?

So our earliest builds paved a road from zero to a validation of that situation. The virtual bank account management components therefore pre-date many of the visible user interfacing components. Net result: building on a solid foundation, and building with increased confidence.

Pick a Date, and Stick to It

This is just one way in which the whole organisation culture has to be aligned: It’s a startup. There’s a runway. There’s a time limit. Don’t turn it into a race - this would be stressful and mistake-prone - but do accept soberly the reality that “we have to have it done by the Nth of X, otherwise we have failed”.

It’s likely you have very little control over this date. So avoid the natural inclination to put that single-most crucial fact in your mental blind-spot. Instead, put it Front and Center.

And once you’ve done that, go about shaping your Release Backlog to fit neatly into that timescale. See next section..

Allocate, Don’t Estimate

Task Estimates. Dependencies. Sprint point wrangling. Post-mortems. Arguments. Entrenchment. Resentment.

We avoided every single one of these by cutting out estimations. Simple.

OK, so you can’t just hurl yourself into the void and trust it will be OK. That’s an equally stupid strategy as estimating a whole project’s duration as the sum of the estimates of its expected component parts (which is a very stupid strategy, make no mistake).

So, what did we do for Haboo? It’s so simple, it will seem unreal:

1. First, we took a toffee hammer to our expected “Must Haves for v1” product picture and broke it up into a series of features / behaviours which feel like they each ought to be achievable “in around a week”
2. We wrote each of these on a small sticky note, just 3 or 4 words describing it (no detail!)
3. Then, we counted the number of weeks between “then” and the Release Date
4. Finally, we pulled into the Release Plan circle on the whiteboard the number of tickets that corresponded to that number of weeks
5. We then stared at it and moved things in and out of the circle until each member of the leadership team was happy with the aspirations implied

Now, the real planning magic is - to be honest - in Step One there and if you’re looking to this blog to find out how to do that for your own project, then you may just have to engage with me directly. (The same goes for advice on “yeah OK but how do we keep those things inside their one-week timeboxes once we’ve started?)

But I can tell you now - for free - that if you do the above effectively, IT JUST WORKS.

In doing so, you can say “goodbye” to:

• story pointing meetings (dear god, these are unbearable);
• arguments over agreed scope at planning;
• crazily verbose task tickets detailing the “agreed” scope to avoid such arguments;
• the sense of dread and weight that an engineer feels opening a work ticket that contains an eight minute read just to get started;
• exhausting and counter-productive stand-ups where everyone has to massively context switch throughout.

Honestly. Just allocate one week to each task. Try it.

Keep Your Tech Team Tiny

There is such a tendency in CTOs of startups to want to Scale The Team and Increase Capacity, inherent in which coupling is a massively flawed assumption that the first will in fact lead to the second (spoiler: it doesn’t).

In my honest opinion, this desire is an innate, unconscious reflection of the (regrettably) patriarchal air that Tech still has. These men - again, IMO - want to Build Their Tribe and Start Their Empire, even if their conscious brains are telling them it’s about sprint capacity and feature delivery.

At the early stages of a Startup, this is a massive mistake. Instead, sticking with a micro-team will cut down on:

• excess cost;
• excess discussion (and the excess cost involved in time wasted talking);
• unnecessary and expensive development activities (lengthy code reviews, silos of authority, cross-cutting coordination, service teams, etc);
• male chest-beating competitions (this is the polite version) disguised as “constructive feedback”.

Also, with a serverless backend such as ours at Haboo, your team is naturally smaller anyway - see this blog post for why.

Complementary Cultures

Delivery of delightful tech product is a marriage of art and science. It’s the multiplication of organic product values with shrewd engineering science.

You will need to work hard to put this, and to keep this, in place.

It starts at the top - with the relationship between your Head of Product and your Head of Technology being the most important single relationship of the whole endeavour. Each needs to be open-minded and prepared to give some ground in support of the greater good. I would advise that these two people diary in regular, relaxed, almost “off the record” relaxed chats about “next” and “later” aspirations.

Once you have that solid, single-minded approach in place, you need to work hard some more to try to overlap feelings in the two teams, to generate a kind of symbiotic empathy (buzzword bingo meltdown).

This sounds like lunacy, I know, so let me give you an example from the Haboo project:

A core “feeling” of the Haboo product is that it works the way you do - This meant that when designing even the earliest architectures for the repayment processes, this facility needed to be infinitely flexible. It was our aspiration that we truly could have a different individual schedule / cycle length for each Customer (weekly, daily, hourly, every other day at 9am and 1pm alternately, etc, etc) if we needed to and - crucially - that this would present no problem at massive scale either.

The result - a micro-event driven architecture leaning heavily on AWS EventBridge Scheduler and Step Functions - was the result of keeping all these feelings on the table even when doing the tech whiteboarding.

Tech should revere the product, not restrict it.

Another way of putting this is: Don’t lose the organic quality of system design - it’s not all science. Tech can too often lend a too-masculine outlook to the solution design of products, and this will find its way into the experience, somehow.

You have to stay true to The Vision.

Conclusion

As you will have deduced fairly early on, this is not a technical post. “How We Built Haboo (The Tech Story)” could indeed be a post for another day, and would wax lyrical and long about development practices, tool choices, AWS architecture, how to minimise tech debt, the benefits of automating early, etc etc etc.

I am a technologist, and the delivery of all those things represents a large part of my actual work, but I truly believe that for the magic to happen, it’s the organic, human stuff you need to get right first. And that’s why all the above paragraphs are devoted to just that.

In short, this post could be summarised as follows - In order to reliably Zero to One your way from dreams to a working product, you must:

• Always be Delivering - Build continuous handheld delivery into your weekly cycles
• Face your Demons First - Tackle biggest, most worrying challenges at the start
• Pick a Date, and Stick to it
• Allocate, don’t Estimate - Forget guesswork on project length; cut up your product into roughly week-size chunks and match count to calendar
• Keep Your Tech Team Tiny - No more empire building, boys
• Have Complementary Cultures - Harmony and togetherness for Product and Tech. Namaste.

About the Author

I’m Mark Henwood, a highly product-focused Startup CTO. Operating at both commercially strategic and hands-on levels, I delight in taking early stage visions and converting them to working, scalable products with a minimum of drama. Please feel free to reach out to me on LinkedIn or email contact@mcbh.co.uk to get in touch.