Hey there!

Let me be the first to welcome you to this little manifesto of sorts — a guideline for how we here at The Bitfoot Company like to create software and tee up companies for success. In some ways, you might even call this an agreement, a social contract. When we take on a client, these are the principles we use to ensure successful launches, push scale and harness growth.

If you’re in a hurry, here’s the whole kit and caboodle summarized in two handy points:

1. If you’re breaking things, you must slow down
2. Limiting costs and providing strong UX is all that (really) matters

Still with me? Great!

Let’s explore both of these items in just a bit more detail. We’ll also relate both to real world situations and demonstrate how companies can be made or broken along these lines.

Point 1: Do It Right the First Time

This one is, rather obviously, a direct counter to “move fast and break things”, the expression made famous by Meta. Though, they themselves have not earnestly followed it as gospel since at least 2014.

So why do we still hear it? From my time in the VC-backed accelerator world, I can personally attest that this expression gets tossed around a lot. Both from mentors in the field and early-stage founders alike.

But like… why?

What about moving fast takes priority over not breaking your product for end users? Why is shipping a feature that’s brittle and will not stand up to edge cases a value add? Is an MVP that only has happy paths really a viable product in the first place?

There’s a seductive logic to the “move fast” ethos — the desire to quickly (ie. For as little cash as possible) add value (ie. Get money out of customers) and grow the user base. A growing user base, of course, means more cash to add more features, repeat as needed. Obviously the faster a company hits growth targets, the sooner it will be profitable, sustainable, marketable, etc.

On paper, this sounds great! Let’s get a bunch of engineers in a room together and hack out a minimum viable product in a single weekend. What could go wrong? Hell, building a micro-SaaS with AI and vibes is kind of a thing right now, why not just do that? Grab some Redbull and make those dreams happen!

Let’s create a hypothetical — your app is a calendar platform that allows users to sync a variety of calendar types (Outlook, Google, Apple, etc.) into a consolidated location. The sign-up flow allows users to add a calendar for free, then charges $15 / month for features beyond that. Starting from scratch, you want to go to market after one month of development.

Say you do a large marketing push shortly after going to market with your rushed MVP. It took four mid-level engineers (conservatively $120k USD / year per engineer) one month to slap together the v1.0 of your product. That’s ~$37,000 invested. However, only Google calendar integrations have been tested and only in code because there was no time for QA. Within the first two weeks post-launch, it’s abundantly clear that Google and Outlook are the two most popular calendar options in that order.

After launching you quickly realize that Outlook is very buggy. The API latency means not all events are synced properly, creating a new event on that calendar doesn’t work and your users aren’t progressing to the subscription stage because of this. And forget about the other calendar integrations, they simply don’t work.

Instead of working on features to differentiate your app from others on the market, you’re in absolute scramble mode. User drop-off is very high while your team spends a month ironing out the kinks in Outlook integrations, costing an additional ~$37k. By the end of the month, there’s a robust test suite for Outlook and some manual QA has been done. You’re confident the issues are (mostly) resolved.

At this point, you’re almost $75,000 in the hole and the number of users you’ve lost out on is hard to calculate. In general, people aren’t forgiving of poor UX. And if the second most popular calendar integration in your app didn’t work for most of the launch month, it’s unlikely the majority of those users stuck around to pay you a subscription.

So let’s stop to isolate a key problem with the entire “break things” way of thinking — you stopped doing it! After a month of moving quickly and shipping kind of broken products, you had to stop and invest another month’s worth of capital into fixing the problems. Not only is that a change in paradigm — even if you immediately go back to breaking things — it’s a costly one. Assuming extremely poor user retention and an initial runway of $100k, you’re now left with $25k to burn, only two stable integrations and low MRR.

Finally, I’d like to point at the fact that if you had solid Agile principles under the hood during the first month, you very likely failed to keep up the pace during the scrambling period. Moving from a proactive mindset to a reactive, bug-oriented one increases burn out, reduces productivity, and leads to additional product instability through regressions.

So what gives? What’s the alternative?

Put simply, slow the eff down! If you’d prioritized stability and positive UX from the jump, you could have budgeted three sprints (two weeks each) to development of just the initial two offerings (Google & Outlook), then spent a final sprint chasing bugs. You’d launch with the same capital invested, but with a rock solid platform demonstrating promise and already delivering a quality experience for the most popular services your users have.

The business impact of this is likely too obvious to dig into, so let’s quickly highlight the emotional aspect. There will be user-reported bugs that need fixing. But you’ve thought through the edge cases, written tests and done as much QA to match as possible.

You can be confident that the product you’ve invested a lot of time and money into building is sturdy. That advantage will not go away! The house will not immediately fall over now that it’s been built! Your app has lasting value that’s quantifiable.

This puts you in a way better position to either focus on shoring up the remaining issues as they crop up, or pushing again for more features in a structured and organized way. All while the app chugs along, gathering up users and boosting your bottom line. No panic needed or made inevitable!

Point 2: Be Laser-Focused on What Matters

Suppose your calendar-focused SaaS is gaining traction and life is good. You’re now at a critical juncture where a few options present themselves. Perhaps you’re trying to decide between broadening the number of integrations versus deepening the features you can currently support. What’s the right answer?

Always make decisions with the end goal of maximizing user experience and end-user value. In addition, if you can make calls that cut costs without hurting UX, that’s a massive win.

Here at The Bitfoot Company we very firmly believe that our two prime directives go hand in hand. If you’re being careful to measure twice and only cut once, you already have the space to determine what should come next in your product roadmap. Likewise if you’ve minimized tech debt up to this point by going slow and smooth, you have much more freedom to focus on the value you’re providing to end users.

To loop this back to the calendar app, assume there’s a strong foundational integration with Outlook and Google. There are users that have asked about using Apple in addition to these two. However, there’s also an opportunity to deepen the feature set currently available — syncing user invites when a meeting is modified or retooling the user interface to clean up confusing workflows, as examples.

There’s really no wrong answer here, though the smart money likely says adding additional features and improving UX as a whole will endear the brand to existing customers — as well as new ones. What you should not do, is disrupt existing workflows for the sake of making “improvements”. You’ve got an incredible foundation to build on, one that’s lean and supports a growing number of users.

Thinking about adding an AI chat bot? Stop it! Pondering adding a time tracking and invoicing suite to the application? Not right now! And whatever you do, definitely don’t pivot to video.

When making product roadmap and architectural decisions, simplicity is your friend. What’s currently bringing value, and what’s low-hanging fruit that will create even more value for customers? What can the application architecture easily accommodate this quarter, if prioritized? How about in a year? Don’t overthink it.

In summary, software development doesn’t have to be so hard. It’s our emphatic belief that with a little planning, some careful consideration and a heaping helping of smooth operating, it can be a pleasant (and lucrative) experience.

And if you’d like to talk to us about helping you build or expand your next project, don’t ever hesitate to reach out.