Mud at the Finish Line: The Reddest Flag of All

Many clients have told me that building their product feels like running a marathon. 

And I get the sentiment. 

When you begin, you’re energized by your idea. Folks cheer you on from the sidelines. The first few miles breeze by. But somewhere in the middle, you get a nagging pain in your ankle, or a calf cramp you just can’t shake. The course is steeper or the weather is colder than you expected. You walk a little, you run a little. You fall behind your goal pace. Though imperfectly, your product comes together.

Then you see the finish line ahead — your product launch! Exhausted and sore, you eek across the line and collapse. You did it! 

This is absolutely the worst way to think about your product. 

By the time a marathon runner crosses the finish line, they are the most diminished they are through the entire race. 

For your product, launch isn’t the finish line. It’s the starting line. Your product is just beginning its race. At launch, it should feel vigorous, strong, bulletproof.

But that’s hardly ever the case. So often, more problems crop up the closer an app gets to its launch date. In the development world, we call this mud at the finish line. 

And it’s the biggest red flag of all. It’s a sign that a project has been built wrong from the very beginning. While it may get past the starting line, it won’t be able to run the race ahead of it.

A Better Expectation

Building an app is much more like building a new car. Its components — engine, transmission, chassis — have been engineered to the finest tolerances. They’ve been tested and re-tested and combined into the final product with great care.

On the showroom floor, it absolutely shines. When you pull it off the lot, it feels eager to be driven. The pedal, the steering, it all feels tight, perfectly aligned. You have utter confidence in it. You know you could drive it full-out for miles and miles. 

Now imagine, as you drive it for the very first time, that you hear a whine coming from under the hood, or the clutch hiccups as you take it up to highway speed. In a brand new car, you probably don’t think of it as a one-off issue. You doubt the integrity of the entire machine. 

That’s what your expectation should be for your product.

Building It Right Means Building is Boring

So how do we get there? One component at a time. 

We develop each part of your product in isolation. These are called “sprints.” When a sprint is complete, it means that component is finished. It works how it should. We test it against well-defined acceptance criteria to make sure it does. 

Then we move on to the next sprint. When we finish that one, we test it in conjunction with the other finished components to make sure they all work together seamlessly. And so on until it’s done.

This is how we know that at any point in the project, what we’ve done so far is good and solid and ready to be built upon. 

Meanwhile, the client has designs for each component, so they know how it should look and work. Our QA team writes release notes for each sprint and sends the client a video demo showing that the product functions as expected.

This is what makes it “boring” — the plan has been relayed to the client, and the fulfillment of it happens on time with no surprises. 

Sure, we help clients think about the stuff they don’t know they have to think about, like what an error message should read. And of course, we throw in little micro animations and other extras that round out the experience.

But in no situation should you come away from a sprint with a list of issues that need to be fixed. 

A Rough Start Makes For a Rough Life

The process of validating a project’s components thoroughly at each increment falls to our Quality Assurance team. I think of them as the execution layer of a project. Though they aren’t the ones actually writing the code, they test it and provide the support that ensures all the pieces add up to the bigger vision. I’ve written about their work here and here. 

If your project is suffering from “mud at the finish line,” it likely indicates that the checks and tests weren’t done along the way. It isn’t these final steps that are mucking your product up. It’s been built wrong from the start. 

I can’t overstate the importance of building your product right from the jump.

• Fixing bugs will create new bugs.

• Because the code is a mess, adding new features will take more time and money than necessary. 

• Your app will become brittle – that is, it won’t function in the face of unexpected conditions. 

This technical debt makes it impossible to scale, evolve, and make money from your product. You’ll end up spending more time and budget maintaining and repairing it than actually making it better.

Just like a badly built house or car, it’ll become a money pit that you’ll eventually be forced to abandon, or tear down and rebuild completely.