It's been one of those days where my early morning hours are ruined by something I'd rather not go into details about and then the later hours throws me at information I have to sit in silence with.
I was reading a post on X and it got me thinking about a concept strongly promoted within the tech industry, at least in recent years.
The concept of "building in public."
If you follow conversations around this closely, you'll learn that there's a strong leaning argument for founders to build and ship aggressively.
Using new data with each release to improve or scale upwards.
The central idea is to go fast, fail, learn and grow from there.
So here I am, sitting in a dark room with an after scent of deodorants used maybe 5 hours earlier, with an itch in my brain that translates, roughly to; Does failing fast beat getting it right slowly?
I'm not doing math, I'm just thinking generally but I cannot help but want to consider the costs.
But that's the thing, both sides have costs.
A slow build that extends 6 months, 3.5 years maybe, can cost a lot, just as much or more than the bill for shipping within weeks with repeated hits of failure to extensively impress the markets or even make it above the loss line into the tiniest of net profit margin.
Systems, cost cushions, talent
Since we led this with talking about costs, here's what I think, more broadly.
At the end of the day, we're trying to figure out what or who comes out at the top, the one willing to fail many times and putting more out within shorter timeframes or the one building and launching slowly, prioritizing perfection.
The more I think about both scenarios, the more I believe the deciding factor isn't the "time."
When looking at raw monetarily costs, either scenarios can be catastrophic. The cost cushions, being whatever or whoever is funding the builds, will need two other things to have a chance at having a successful venture.
Those two things are systems and talent.
When trying to build something into a success, you need talented people not gamblers. Building and failing fast doesn't mean gambling, it means doing enough within the shortest possible timeframe to test a market.
Talent is needed here.
And building slowly likewise requires people that understand how to build and optimize when timeframes extend into years to ensure compatibility with current markets.
To conclude, both scenarios require systems to supports the workflow of those talents to build within experience.
So, does failing fast beat getting it right slowly?
Not necessarily. The true decided factor is who has the talent, the compatible workflow system and cost cushion, to support the build.
With AI getting into the frame of today's business world, we're going to be wowed with how much change we will experience in a few years simply because the cost to build, fix and scale has been greatly reduced.