Originally published on PURE LAMBDA
A software factory is a global term describing a company that provides software as deliverables. In other words, it is a company that is “ offering a structured collection of related software assets that aids in producing computer software applications or software components according to specific, externally defined end-user requirements through an assembly process.”
Highly standardized and componentized, engaging with a software factory can be helpful for young startups launching their product or testing their products on a market segment.
As Founder of PURE LAMBDA, I often receive requests from founders on what type of software factory to choose or what to check when selecting one. That is why I have decided to build a quick checklist of the do’s and don’ts for founders when engaging with a software factory. How do you make sure that a software factory positively impacts your business?
When and Why use a software factory?
Usually, software factories are used to build a prototype, an MVP (minimum viable product), such as a mobile app, or a website. It is specifically handy when you start your company, which could go hand in hand with how you structure your team. You could choose in the beginning to have one person fully dedicated to managing the relationship with the software factory.
The majority of startup founders that PURE LAMBDA has worked with, have used software factories to prototype their MVP or develop a new feature quickly. When you start a company, you will need to build a prototype to test the traction, so it can be a good alternative, instead of hiring an employee, to outsource to a software factory to build it.
At PURE LAMBDA, we recommend building the early prototype using no-code because it is quick and cheap. And then, when the product is tested, you can hire a software factory to create the first (and accurate to the need of the market) version of the product.
If you have a founding engineer, do you need a software factory?
It really depends on the scale of your product. If it is a small mobile app, then maybe it is the founding engineer of your startup who will build the mobile app. If it is a simple website, perhaps your founding engineer endorses the role of a full-stack engineer and builds the website directly.
But if it is a larger project, it can be challenging to build. In this case, your founding engineer might act as a project manager with the software factory.
The first steps with a software factory: what to check?
The fundamental element to keep in mind when engaging and negotiating with a software factory is to pay per project and features and not per hour to avoid cost escalation. Software factories prefer to work per hour, but you should avoid it. Good software factories are open to being paid per project, bad ones are often not.
You need to check the software Factory’s reputation by thoroughly reviewing the website and recommendations when you start the project as well as their LinkedIn and other social media. A software factory with a solid reputation will have more to lose in case of conflicts with you.
Software factory companies are global, so you will find some all around the globe, in France or India, for instance. Obviously, the ones located in India, South America, or Bangladesh will be much cheaper than those based in Europe or North America. But it does not mean the quality is lower!
Companies such as the Big4 can be used as software factories. Working with a Big4 will be very costly, so it is certainly not applicable for a startup, but it can remain an option for a specifically complex or larger project.
Project Management: how to engage daily with your software factory team?
It seems to be stating the obvious, but a successful relationship with a software factory means careful and serious project management. There are no gaps in the project description, and every role has a very well-defined function.
It is essential to schedule periodic meetings with the software factory so you regularly check the project’s advancement. Make sure to plan those meetings ahead of time so it does not come as a surprise for either party. We recommend at PURE LAMBDA that you see a demo of what they are in the process of developing at each meeting.
You also want to have a list of tasks accessible to you and the software factory team. For that, you may use a tracking and tasks management platform such as Trello, Jira, or ClickUp. Having such a tracking platform is not only beneficial for the regular meetings you have with the software factory team, but also useful for you to assign additional tasks (such as bugs), or follow at what stage they are for each task.
For each assigned task, you need to have very testable, verifiable acceptance criteria for each of them. If you are building an API with the software company, you want an example of the API input and output. You don’t want something that “works”, but you need to define from the beginning what “works” means.
In theory, when you work using the agile methodology, at the end of the Agile sprint, you should have a working deployable code that you own. By own, it means that the code is hosted by you on your server and on an account you control.
Divide and rule: the golden rule to manage your relationship with a software factory
For instance, if you build a website, do not use the same company for the design, the front, and back end. It is the golden rule of “divide to conquer”.
You first hire a designer to design the full wireframe. You can use one of the multiple online platforms to find one, for instance Fiverr.
Then you can hire a software factory to do the front-end and implement the design you provided. The wireframe you have will act as verifiable acceptance criteria.
Potentially, you can hire another software factory to build the back-end, implementing an API that the front-end team will use to render the pages.
If you let one company do both, it can become complicated to understand the data flow or can simply be poorly implemented. It will also make it harder for you to know what is going behind the scene, between each component of your architecture.
On the other hand, working with two software factories will be time-consuming and costly so you need to balance what is important to you based on your budget, time constraints, and available team members.
The critical point is to never outsource your core values, such as your core algorithm. Otherwise, you are no longer a tech company but a consulting company aggregating what others have created. Internalize as much as you possibly can.
Costs, Length, and data protection
There are no specific rules regarding costs and length as it depends on your project and its complexity but also your time limit, how people need to be involved, and where you offshore the work in the world. Typically the project with a software factory runs between 3 to 6 months.
One thing that is certain is that there will be delays. In the plan regarding budget (and budget should always be money as well as time, do not forget time), make sure to add 20% extra time at least. If you think, or they tell you that it is going to take 3 months, put 4 months in your internal planning instead.
On the costs side, it is vital to not forget to estimate the running costs of the project once completed. Once you have the code built by the software factory, you will have to host it somewhere. This means you will have to pay for those hosting fees and database monthly maintenance.
Do not forget to sign an NDA with the software factory to protect your data and intellectual properties.
And keep in mind to check precisely what you have in the contract regarding the interaction with the developers. If you have a point of contact in the software factory, that is an outstanding engineer, and if you don’t have a specific clause in your contract, it can also become a good opportunity to hire a talented engineer.
The no-code movement and the future of software factory
According to Business Wire, the future is low-code or no-code, with an expected growth rate of 44.4% by 2022 to $27.23 billion, up from $4.32 billion in 2017.
In the future, software factories will not be used anymore to build the code from scratch but rather to assemble the features and components using no-code tools, accelerating the building process and overall completion time. We now see engineers in software factories specializing in no-code technologies.
In a nutshell: Software Factories 101 with the 12 points Checklist
We summed up the items to check when engaging with software factories in a convenient checklist.
- Pay per project/features, not per hours
- Check reputation
- Schedule periodic meetings
- Have a list of task that is shared between you, and them
- Testable, verifiable acceptance criteria for each task
- Make sure you have access to a deployable code at the end of each sprint
- Make sure you control the versioning platform (GitHub or Gitlab)
- Make sure the used technologies are recent and modern
- Make sure there are unit tests and automated tests
- Have a place where you can submit bugs and TODOs
- Test / QA yourself and submit bugs to the list of TODOs
- If possible, do not use the same company for the design / front end/back end
- Design can be done with a design freelancer that will fulfill your UI requirements
- Front-end will implement the design you provide, and acceptance criteria will be described using the wireframes
- Back-end will implement an API that the front-end team will use to render the pages