Building quickly is building dirty

Hi there, Nicolas here! Today, I'd like to share my perspective on the “Ship Fast” philosophy.

“Ship Fast” is a development practice that focuses on building your product as quickly as possible to get it to market early. The goal is to have customers (and thus revenue) as soon as possible. This means concentrating on the features that add the most value during development to get to the essentials.

However, as the title suggests, Tom and I are not big fans of this method. And for good reason, we built Crane It using this method, and we're now regretting it.

A short-term technical solution

In the “Ship Fast” philosophy, the only thing that matters is producing the most essential features of your application. However, there are many other important aspects to consider:

• Responsiveness: Ensures the application can be used on mobile devices
• Security: Prevents the application from being a sieve
• Tests: Make the code more robust and reduce the number of bugs
• Database: Often the foundation of the application; if poorly structured, the application will be too
• Code Structure: Avoids duplication and facilitates code evolution
• Clean Code: Important for maintainability

All these elements take time, but are just as important as the features. It's the combination of all these factors that results in a high-quality product. If you neglect these elements, it will lead to “technical debt.”

"Technical debt" refers to the effort required to bring the software up to date with current knowledge and skills.

The more technical debt you have, the harder it becomes to navigate, debug, improve, and evolve your application.

For us, evolving Crane It has become complex and delicate: no tests to verify that developing a new feature doesn't break an existing one, for example. So the application will evolve very little until the day we decide to completely overhaul the app to better meet our needs.

What philosophy to adopt

The advantage of this philosophy is that it allows you to have a product quickly (even if it's low quality), and thus acquire users early; if only it were that easy. Once you have your application and want to commercialize it, there are still many things to consider:

• Legal Structure: You can't sell a product if you're not authorized to do so
• SEO (Search Engine Optimization): Improving it helps you rank better in search engines such as Google
• Marketing: To convert customers passively
• Sales: To approach and convert customers
• Communication: To let your market know you exist

These are all elements to consider when it comes to the success of your project. For Crane It, we didn't have a well-defined and effective commercial strategy, which is why we have very few users today, and that it's not enough to make a living.

Conclusion

From this failure and the difficulties in evolving Crane It, we've learned a few lessons:

Move fast occasionally

Moving fast can help achieve a short-term goal or deadline. But this “rushed” phase should not last a month; it should last a week at most.

Take the time to structure your project

Before building a skyscraper, you lay solid foundations. The idea is to create excellent foundations for the application with a good choice of tech stack and database architecture. Then, you build the floors of this skyscraper (i.e., the features of the application) one by one. Solid foundations will greatly help with future evolutions.

Work clean

Implement measures and best practices to ensure clean code. This makes it easier for everyone to take over each other's code.