.. you could be looking at a do-over.
Choosing the right business software design team can be one of the essential factors in your startup's success. Getting the right people to build the right design early on is critical, or you might have to do it all over. Whether you outsourced or built it in-house, that could be a fatal outcome.
This article will give you fresh advice and tips to avoid strategic errors. These are perfect for a startup founder or an already successful entity ready to throttle up a product design after your third round of funding approval.
When to cut your losses with growing Technical Debt
One example of Technical Debt is when software code is poorly written, and your team must rebuild it. Another example is when code development begins before a design architecture is decided. Make the wrong choices on either, and you take on too much technical debt that can sink your company or stagnate feature development to the point that your customers leave for the competition.
Technical debt is a beast that causes a loss of focus at all levels and can lead to all development halting to a stop. Avoid these pitfalls so your company can pivot when it needs to.
The first casualty is lost opportunity costs for your small business. When you try to fix the technical debt because you did not take the time to build your software the right way, you don't develop new products/features, period. Higher engineering costs hurt profits, and your investors will get irritated. You like to sleep at night like most people, don't you?
Software developers hate poor code causing turnover in your engineering team.
Poorly planned initial software design translates into wrong code. It slows down your organization. And if you're outsourcing work, it means that within the 3rd party vendor you contracted with, you will work with a new developer on every project.
What processes will ensure your company prevents a software do-over?
You need good communication with your lead engineer/project manager in almost day-to-day contact.
Insist that your Development Team (devs) ask many questions about your business. Your company might find this irritating because Devs keep asking you questions. It seems they don't want to write code at all and want to talk with you instead. But communication is a good thing. If your Devs are not asking you questions and getting deep into your business, that is a big red flag.
Design your software for future capacity to pivot to new market opportunities.
Engineers should be interested in your business so much that the code they write solves your business's actual problems and gives you the future capacity to adjust to changes inyour industry.
Some startups wrongly choose software developers instead of designers.
It happens when a company stakeholder writes, for example, a five-page description of precisely what they want the software product to produce. Acting on this mission, they decide to outsource it to a pure software Dev shop that tells them, "Yes, we can build this in two to four months!"
And you send them off on their way to build it. Since this dev shop likes to make only code and does not like to ask questions, the product you see in two to four months could be a real disappointment.
They didn't ask us any questions about traffic estimates.
Pure code developers tend not to ask clients any questions about traffic estimates. Recently my development team was fixing a client's version 1.0 built by previous devs who took 26 hours to run a single process, whereas it should have only taken 1 to 2 hours.
The cause? The devs didn't bother to ask how much data the system would process. They chose a single non-scalable Docker container instance iterating through data in a single foreach loop. Designing it serverless would have been better for the client.
We changed it to AWS Lambda, which scales up to 70x instances daily within a few minutes. We fixed the problem, but this client paid twice for the same thing because the previous contractor's first solution did not work at all when completed.
Some companies are willing to live with Technical Debt.
a. "The Hack" -- everybody is aware in the company that the solution will not work, for example, if the customer base exceeds
100 000. But everybody agrees that certain parts of the system will need replacement.
A better alternative is that the design architecture prepares for it from day one. Then running a company is not a hassle in year 2 or 3. You change some parts, not the whole thing.
A word of caution: Developers usually do not like "Hack" solutions even though the situation may call for it. It is hard for engineers to devise a temporary solution that needs the core engine replaced. You risk having a year's worth of downtime.
One example of saving operational costs and engineering overhead is to avoid the need for microservices from the beginning. It's better to choose a monolithic system but structure the code so that you plan to extract modules into separate systems when the traffic is high enough. You still work with GCP or AWS, of course. You know which cloud services you will use when the company scales.
b. "The Mini-Hack" -- Let's say you cut some corners but not very many. After the initial version of your software build, you operate it by developing 90% of new features and 10% to fixing known tech debt. This keeps your software lean.
It's okay to do "The Mini-Hack" for a period, but again, business stakeholders should be aware that the day of reckoning to pay for this will come sooner than later. Sometimes it makes sense to do "The Mini-Hack" to grow fast.
When to build your software well engineered from the start
A startup's reality is that you rarely get the budget to do it the whole right way from the beginning. The only exception here will be if your product IS the technology itself. When your clients are the engineering community. It needs to be bulletproof from day one.
When your software is bulletproof
Your company feels more in control when your development team properly explains the process and how it's built. Working daily with a proficient full stack development team will grow your company's engineering instincts by association. A business owner learns what is hard/medium/easy to develop without always talking to engineers allowing for faster decision-making.
So, when will you have the time to build it over?
When you build your software development the right way the first time, you make a conscious choice to save money, time, and maybe even your business. Design first before you develop. Choose a team that asks many questions and communicates closely along the way. And allow your software to serve with extra capacity, enabling you to take advantage of market opportunities. You got this.
Marcin Ziolkowski writes about business software development strategies for early-stage companies. He also founded Goddit LLC. Based in Denver, Colorado, the company is a burst tech dev, full-stack software development team.
