Skip to content

From PoC to stable repositories

Published: at 07:11 PM

Been in the industry working at multiple companies with different stages of their development cycle, I’ve been in various of situation for projects. Either if that is a Proof of Concept, a beta version or a stable build, it has taught me some tricks and tips that might come in handy if you are in a similar position. Lets go through these!


Prolouge

Developing a product is not very different than learning to program for the first time. It takes iterations, sometimes when you encounter a problem you need to go back and re-deo your implementation as well as thinking of scenarios where your code will be volatile.

The similarity in the development of a product (in terms of Software Engineering) is close. In the start of a project you might only need some requirements to fit your Proof of Concept, while over time you will need to follow design prinicples, technical specifications or versioning of your software.

In this post I will chronologically go through how projects evolves into a state of art products.


Proof of Concept

You might know what a Proof of Concept is, but it’s worth revisiting. The term denotes a product that is created to show steakholders or your boss that an implementation works.

Early Stage

In the early stages of a product, you might have created some source code structure, but it’s far from perfect. Ideally the structure of the code will make the product itself easy to develop without any major oversight of process to create a deploy.

In this stage, most of the main features of your product is made, speed of development is good, but keep in mind that fast development means more verbose code and messy process of distributing your software.

Good

Bad

Intermidate Software

Ideally this is where you want to be as a startup. You have good source structure, code style is followed, formatting and some documentation of how to run the repository is given.

In a startup environment this is where you want to be. In the union of stable software with strict, well written and documented code and a fast phased development.

Good

Bad

Stable Product

In stable products your CI/CD for development, staging and production is good. Like mentioned in the last section this is where you have good abstractions of code, well documented code, documentation is top-notch and your source code is very specific. Ideal in a situation where your product and features doesnt change much (but at the cost of slow churn!).

Good

Bad


Conclusion

All of the stages a project is in depends of the requirements and vision of your product. Personally, being in the middle of a stable product and an intermediate solution creates more value while having good enough boundaries for a developer to make good code.

Thanks for reading!