You may have just received a grant, a pre-seed funding round, went to the bank, or decided to use your own savings to build a startup. You may be a serial founder, industry expert, graduate, or simply a young professional tired of spending their life paying back a mortgage at a 9 to 5 job. Does any of the scenarios sound familiar?
At this point, you’ve already gathered some funds. Unfortunately, a grant or pre-seed funding can't be spent entirely on a product. There are other expenses, and keeping them balanced is like juggling a dozen balls at once. You are in a position where the investor expects you to deliver a product or service at specific conditions and certain timelines – and more often than not, it turns out that building a relatively simple mobile or web app may absorb much more resources than expected.
In this article, I’m about to outline some cost optimization practices that’ll certainly help you not to blow your startup budget out of proportion.
Being a startup is a condition, not an excuse
It’s a common belief that standard market rules do not necessarily apply to the startup ecosystem. Early-stage founders often expect that the services offered to the corporate world will be cheaper in their case just because the company they established is listed on Y Combinator instead of NASDAQ. The problem is that services such as setting up AWS environments or mobile prototyping using InVision are delivered by top professionals with extensive experience in a given field. Their hourly rate won’t change because of the startup’s budget limitations.
Instead of increasing the estimated cost of software development right away, I’d recommend adopting a careful and responsible attitude towards resources. Initially, you might be tempted to invest in a bigger team – but remember that software development is about quality over quantity. A small but experienced team is usually sufficient to launch a successful MVP as it provides more value and displays higher velocity.
Instead of cutting corners by looking for developers willing to work for half of the standard market rates, acquire an experienced team and make the best use of their time. Skilled IT experts are more acquainted with various libraries, tools, 3rd party integrations, so the learning curve is minimal throughout the project. Their knowledge also allows you to be transparent about the budget. With financial limitations at the back of their heads, experienced developers can come up with money-saving recommendations like:
Let’s get rid of live chat at this stage, so we’ll save plenty of hours on WebSockets.
Instead of building two native apps, let's involve Flutter and Rive to meet the expectations at lower commitment.
Having experienced developers on board from the beginning also influences future costs. One example is that of the architecture, whose shape is determined by developers’ initial decisions. Then, the clarity of the code simplifies the handover once you’re able to hire first in-house engineers. I could go on about the benefits, but you should get the point by now.
It all sounds very well but employing experienced staff requires some preparation too. Before acquiring senior staff, ensure you can provide them with a proper working environment: development, testing & production environment, ticketing & time tracking, communication channels. You can also enquire if this team already has some established working standards in place. It’s just like in soccer; contracting top-notch players won’t turn them into a vigorously defending & attacking team on its own.
Make your statement and make it strong
Have you ever visited a website or a LinkedIn profile of a startup, and after a few minutes of checking it out, you still didn’t know what this company is doing? Was it because of a poor copy or maybe a vague business idea? If it was the latter, too bad – because it’s an absolute must for a startup building a digital product to explain what it’s all about, what problem it solves, and who can potentially benefit from it.
Startup cost optimization starts when you realize that your prospective users aren’t, let’s say, all football fans, but a group of people aged 25-35, living in big cities, educated and interested in sports, looking for amateur sports events in their neighborhood, watching Netflix, and living in rented apartments. Sounds specific? It should, as your target audience needs to be researched rather than being based only on your private life observations.
User personas created during product design workshops at Merixstudio
Understanding your prospective users allows you to define and prioritize features of the highest necessity. For example, Instagram initially allowed people to publish only photos taken with the app, whereas Uber didn’t allow placing orders in advance. Now that both companies are no longer early-stage startups, they offer users much more.
For that reason, almost every User Experience designer – me as well when it comes to budget optimization tips – would recommend creating a user persona for your product. A persona helps determine which functionalities are key and which level of accessibility and what kind of devices you should focus on from day one.
It’s recommended to have at least 2-3 personas before launching the design process. To create them, you’ll need information that can be gathered through interviews and surveys. And guess what – you can do it (almost) for free! Tools like Google Forms allow you to run a survey among local university students, members of a Facebook group, rock music fans visiting local vintage stores, you name it. What persona characteristics should contain is widely explained in this video.
Once you deal with the target audience, ensure that the developers working on your product can see the big picture. Understanding the business and market context will accelerate the development process and make their work more effective. Of course, not every engineer will become a healthcare expert overnight, but some basic knowledge will help them understand the functionalities they’re working on.
A roadmap to find the way and Agile process to change it when needed
With validated ideas and well-described users, you’re in a perfect position to start planning the development and product design process. Assuming that you’ll acquire an external designer, it would be beneficial to provide them with benchmarks so that they can get a grasp of your expectations. Thanks to tools like InVision, you may launch the prototyping phase before involving software engineers.
There’s a common belief that while building a digital product, savings made on designs should come first. I couldn’t agree less. Speaking from my own experience, I believe money can be best saved when the development of low-priority features is postponed.
Deck of features and some high-level mockups in place allow the dev team to perform an estimation process, which is crucial from much more than one angle:
- The experienced dev team will most likely turn requirements into stories or a list of features. This is the origin of a proper project backlog, which can be easily transferred to your project management tool like Jira or Trello.
- Having defined activities and tasks, you can start planning your project in terms of duration and manpower commitment. This way, you’ll learn how many people you need and how big invoices you may expect in the upcoming months.
- Estimates also help to make decisions regarding QA commitment, Unit Tests coverage, and other important matters to be explained later on.
An estimate in place gives you an idea of how much you will spend – but you shouldn’t be too attached to it. I haven’t heard of a software project where the requirements haven’t evolved during the development process. This may be caused by changing business surroundings, trends, or your competition. Sometimes, switching the order of tasks will do (e.g. let’s develop a student dashboard instead of a knowledge base first); other times, the adjustments of the entire idea may be required.
Anyways, having a well-prescribed deck of functionalities with some tech recommendations in place will help you manage the project even in situations where some of the features need to be changed. It’s like dealing with a long grocery list, where you aim to prepare meals for 12-14 people. You’re already in the supermarket when one of your friends calls you asking whether she may bring her new boyfriend, who’s allergic to gluten. You do not resign from starters and salads, but you need to reconsider your deserts. So you need to pick different groceries, right in the middle.
Staying on the topic of change, let’s proceed to discuss Agile. Modern software engineering projects are performed by self-managed teams, where each specialist is responsible for updating the ongoing deliverables. To perform effectively, it’s crucial to come up with an optimal team setup, so that the IT experts can contribute and deliver tasks in a certain order. In one of the most common schemes, the stakeholder(s) would define business requirements to be turned into designs by the UX/UI designers and in software by the engineering team. Each bit of software shall be tested by QA specialists and then deployed for the final users. IT projects may consist of 10, 100, or even 10000 tasks, and in proper order each one of them should be processed through this ‘conveyor belt’.
To secure the quality and velocity of the work, it’s recommended to come up with possibly highly predictable tasks that can be performed by the engineering team in 8 to 20 hours each. A crucial aspect is reviewing and providing feedback on deliverables, hence the stakeholders’ – including yours – commitment is highly appreciated also during the development itself. Some features may be adjusted at a very late stage, just like the abovementioned grocery list.
To maintain high velocity, self-managed teams are meant to stay in touch and perform Agile ceremonies, like dailies, retrospectives, sprint plannings. Experienced teams shall involve clients and stakeholders in their daily based work.
Another aspect to consider when optimizing startup budgets is testing. Let me make a simple comparison. Imagine you’re building a house. If you don’t have enough tests, you’ll end up with a flooded basement and a leaking roof. Overtesting, on the other hand, will turn your house into a nuclear-proof fortress – a place that’ll keep you safe and sound but hungry because you’ve spent all your savings on security.
Investment in tests, especially in budget-sensitive endeavors can be also compared to the Laffer curve. in mid 70ies, American economist, Arthur Laffer made a comparison proving that no tax revenue is raised at the extreme tax rates of 0% and 100%, and that there is a tax rate between 0% and 100% that maximizes government tax revenue. Just like in taxation (at least from the government's perspective), we may expect a certain level, between 0 to 100, which will be optimal for a particular project.
Relationship between phases of development and testing as represented by V-model
Forecasting the most optimal approach may be impossible; however, introducing some Quality Assurance standards will undoubtedly help you save money by reducing the number of bugs. For this reason, if you review the estimation spreadsheet and see 24-40% code coverage listed there, resist the temptation to see it as a useless tax and perceive it as a benefit instead. Also, remember that the Agile workflow allows adjusting tests coverage throughout the process.
Understandably, experienced development teams can come up with recommendations concerning the basic level of tests. Among the aspects they’ll take into consideration while suggesting levels of tests are:
- Accessibility, meaning browsers and devices the service should be available on. Can we reduce test coverage by eliminating some of them, for example, iOS? Do we need to meet HIPAA requirements (we always should but sometimes we may not afford it)?
- Implementation of 3rd party integrations or external APIs. Testing APIs is usually associated with additional effort, which pays back, especially during longer projects.
- Security-related tests. Some tests of particular payment methods or data exchange are necessary due to local law regulations as well as commonly introduced business standards. Leaking data or unsuccessful payment processing may cause much greater costs than the additional 5-10% spent on proper testing of a crucial part of the system.
Many Quality Assurance specialists recommend starting with at least manual functional tests and eventually extending the coverage as the level of recognized regression increases. Regression is a situation where a functionality or software fragment that worked fine turns out to be buggy and requires fixing. Just like cough, a first showing ‘bugs’ may be a signal to slightly increase the coverage of tests & QA specialists' commitment. Testers’ support helps developers focus on new features and see things that they didn’t initially notice. Besides functional issues, QA specialists also prevent security-related issues from occurring – which may be crucial in services requiring sensitive data.
Another factor is the matter of unit tests, which are usually performed by the developers behind the code. Properly executed unit tests may require additional testing of ~80% of the codebase, which may increase devs’ time spent on this task by 40%. Of course, in many cases, such coverage is not a necessity; bear in mind, though, that finding balance between over- and under testing may be crucial in balancing the costs.
Gathering and handing over the requirements are just baby steps in the product development circle. As a founder, you should see both the details and the big picture. For instance, features that are exciting but of relatively low importance may prove expensive to implement – and you need to be able to let go of them at the early development stages so as not to blow the budget out of proportion. Another example is noticing how being committed everyday communication improves the performance and velocity of your engineering teams, which also reduces the final costs of development.
Long story short, to optimize development costs, you don’t have to resign from the best industry practices. On the contrary, I’d recommend turning them into your credo from day one – especially if your project is budget-sensitive.
Need help getting your business idea off the ground? Check out our Startup DNA offer!