The three year anniversary of Apiumtech is approaching. Like any company that is going through a continuous improvement cycle, a major concern has been, since the beginning, to have MVP and regular meetings between managers. That would permit to focus on the business value and go step by step adding exactly what client want and move forward according to the stakehholders reaction. Also, it would allow technical department to analyze data collected and find what has been well done, but above all, what has been done wrong and how not to repeat it.
In these three years, we have worked with about 65 companies. Of these companies, 20% were foreign companies, European all. Of these 65 companies, 70% were startups, ie start-ups or still in the development phase of your product.
These are some of the conclusions in the realm of the purely technical, we have learned from these three years.
TECHNICAL DECISIONS: CRITICAL PART OF SUCCESS
Sometimes we found very common misunderstanding of the concept of MVP (Minimum Viable Product). This led to the technical part translates to “start it as you can about it is just a MVP”.
In practice, almost always … the MVP does not take one month but its good six months. It is essential to have a serious architecture from the outset so that after those 6 months, the client does not have to redo the project.
Make a “pasteboard” can be very “lean” on occasion and should be evaluated if a little more, can not do it right the first time.
The condition does not develop all the specifications MVP but, if I change something, do not have to redo anything.
In most cases, we have found to do well, not only costs the same but is almost always cheaper.
Tip: Working from the very beginning and as far as possible with “working software”.
More than half of the projects already have started over the technical part
Of all the startups in which we have worked these three years, more than half again we have components that did not work or accidental complexity, could not keep growing functionally. This has not only represented an added cost and not wait for the client, but delayed their product.
Tip: included in the contract with the outsourcing functional scalability because you are paying for a service and this has to be quality. Spaces redo.
WITHOUT AN “AGILE” TECHNICAL CULTURE, THERE IS NO REAL LEAN STARTUP
Lean Startup is a movement with which I agree and respect very much. In these three years, we have attended several Bootcamps in Barcelona and we have also been mentored in Tetuan Valley. We have known great professionals and become good friends. Jimmy Flores in particular has opened our eyes and selflessly given valuable lessons. Jimmy thank you very much !!!
From the beginning, with our background in agile, we can see that Lean has a very solid base. There is however something that we think is not entirely explained:
Lean prescribed small iterations where validate the product consistently. It is in the implementation of this principle where we can not conceive “fast passes” without an excellent technical base.
Take an example … talking about a website that is a very common case … How can we make short iterations if it takes the time to get into production? or … How can we make short iterations if a lot of the time we are solving bugs … or integrating the work of the designer, developer, and content?
Tip: For the Lean Startup culture and practices are effective, assures that the outsourcer is agile: unit tests, continuous integration, automated deploys, functional test automation, SCRUM …
DO NOT WORK WITH COMPANIES “MONO-FRAMEWORK”
There is no magic framework that solves everything, in fact, how difficult it is to work with a framework without relying on, and this is achieved by designing an architecture with well-defined design patterns. If your company tells you that you are outsourcing experts (framework such) maybe you can find another company that does not attach to a framework and you create a dependency from the beginning.
The solution is a good architectural design, not by a particular technology.
In these three years, we have worked with customers who called us because his application was unmanageable. In almost all cases was the typical installation of Symphony, many others were Ruby on Rails, we also have similar experiences with Yii, some quite experimental java frameworks … I’m not saying they are a bad choice in itself, I repeat: technology is never the reason or the success or failure. But if you have to be careful with uncontrolled or coupling of a given framework.
Tip: choose development companies, not specialists in something concrete. Specialization is for insects.
Even you’re not technical… You can (and should) check your product at the tech level
Each piece in the startup has a well-defined responsibility and in the case of CTO is leading the technical part. It happens that a startup is not always CTO. It also happens that sometimes, CTO functions are performed by people without much experience … is normal. In startups that outsource development in any component or whole is convenient to access technical control boxes to operate. That is, we must break the dependence on outsourcing. One thing is that “rise to production” when asked, but if I want to go to production or rollback … I have a button where I myself do it.
Today, there are many tools to control this, and, in particular, is Jenkins or TeamCity. Really … it’s very simple.
Tip: ask to have a control panel where control and monitor technical processes of the application. A startup must be able to measure the speed of development or find errors in a build even if not technical. Prohibited be captive outsourcing.
These are some of the findings of these three years working with startups.
If you feel identified and want to share your opinions or want to raise some other related technical direction in a startup doubt, do not hesitate to contact us. We love to share.
