Unlike startups – which are partial to simpler processes – and larger corporations, where processes are both well established and clearly defined, when it comes to software development, small and medium enterprises, or SMEs, do not always have the required experience. So with that in mind, for businesses wondering how to start a bespoke dev project, we have put together a software development step-by-step guide to help companies learn to navigate this process.
How to Start a Bespoke Dev Project
Here is a list of essential steps required to turn your initial web development idea into a fully realised bespoke solution:
- A Few Assumptions About Bespoke Software Development
- Is Bespoke Development Riskier by Nature or Is Poor Project Management to Blame?
- Why Bespoke Products Fail
- Before You Start a Web App Project
- Key Roles When You Start a Bespoke Dev Project
- The Project Scoping Phase
- Software Development Planning Questions
- UI/UX Design
- How to Choose the Right Software Vendor for Your Company
- Finalise Your Project Roadmap
- Sort Out the Legal Bits
- Time to Start a Bespoke Dev Project!
A Few Assumptions About Bespoke Software Development
Developing a bespoke project — especially when doing so for the very first time — may be pursued for a number of reasons. More often than not, the motivation behind it is to simply become more efficient. You are trying to solve complex business problems by making use of all the available tools (in this case, using bespoke software) and attempting to replace manual operations. While the market will oftentimes already have a suitable product in place, there are certainly some clear exceptions.
Is Bespoke Development Riskier by Nature or Is Poor Project Management to Blame?
Nevertheless, a popular myth exists that bespoke software engineering is inherently problematic, so let’s examine this a little further. After all, in reality, bespoke projects will typically flounder because of negligence in one way or another.
Why Bespoke Products Fail
For those afraid to start a bespoke dev project, here are the most common reasons why bespoke projects fail:
Vague business priorities
Already at the start of development, due to vague business priorities, a number of issues may take place. For instance, If an organisation were to create a system for serving three different company departments, each department would be likely to generate their own specific list of requirements and they could find themselves in a situation where no one agrees on whose features to prioritise. Another unfortunate consequence is when a feature is urgently needed but this is not made clear to developers until it’s much too late to deliver it.
Lack of engagement from project stakeholders
In practice, a lack of engagement from project stakeholders means they will fail to uphold their side of the bargain. This includes ignoring product demos and meetings, failing to provide critical information when needed, not often answering important questions, and being much too busy to verify results – though these are demonstrated throughout development. To make matters worse, at the very last stage of the project, they are often perplexed when things don’t go their way. This is why engagement is often considered one of the most vital steps in the software development process. Without it, the timeline of project development is jeopardised.
Scope creep
Unless you thoroughly understand your goals and priorities, you are also at risk of falling prey to scope creep. This occurs when you agree on a set of features and priorities in the initial phase of the project, but you are constantly being swayed by new ideas and as a result end up enlarging the project scope. Consequently, a 3-month project with a budget of $50,000 may eventually become a year-long marathon with the expenses to match this growth.
Long development cycle
Upholding a long development cycle can also be filed under common mistakes when developing software. This is when you provide no feedback for a long time period. Developers are provided with the initial requirements before you abandon the project for months at a time. Upon your return — to everyone’s frustration — what you originally had in mind was interpreted very differently. This concept is paramount in bespoke development services, as without your company’s continuous feedback, your project could be destined to fail.
Before You Start a Web App Project
With all of this in mind, if you feel that a bespoke solution might benefit your organisation, then it is time to start preparing for your web development project:
Identify key business problems
One of the first steps of bespoke development is to identify key business problems. These will essentially be the main drivers behind your company’s decision to develop a bespoke application. Below are some of the most common examples.
- An off-the-shelf solution is not a good fit for your business, processes, circumstances, or any other individual company priorities, and it would therefore not be the best idea.
- You want to explore new business opportunities. For example, working with your clients, you have become aware of a significant problem in the market and see a way to resolve the issue via software products.
- You cannot afford an existing solution because the product is very expensive. Ultimately, it is often more economically efficient to invest in your own solution than to pay for a monthly subscription fee or a ready-made software product.
Have a clear problem statement
What problem are you trying to solve by means of developing a software product? This will later inform all project decisions and is a critical component in how to guarantee your product’s success.
Prepare and justify the business case to start a bespoke dev project
Your business objectives should define the software product. In other words, you will first have to identify the problem, and then elaborate on how – from your own perspective – the software solution will be able to solve it. Remember to also bear in mind any ideas you have in terms of financing and that this does not necessarily have to be a formal process. It could in fact be extremely simple, but you will have to invest the time and effort in it. So when putting together your business case, consider the following important questions:
- Will this really solve the problem?
- Do you understand your budget from a high-level perspective, with the help of a quote from an in-house or third-party software development team? (e.g. will it cost you $10,000 or $1 million?)
- Would this really be a reasonable investment at this stage of your company’s development?
Once all these arguments are firmly in place, you can then proceed to justification by presenting them to all relevant parties. This will enable you to obtain the support you need from within your organisation. So be sure to talk to senior executives or anyone else responsible for financing the project.
Define your project goal
There should ideally be one goal in particular without which your project is meaningless. For instance, if the entire purpose of the project is for an accountant to generate a list of transactions for a particular period of time, if this feature isn’t duly implemented, nothing else in the project will matter. You will often find that the project goal is at the core of the Minimum Viable Product (MVP).
Don't know how to estimate project time & cost?
Request your initial quote from SPG today!
Get a QuoteKey Roles When You Start a Bespoke Dev Project
In any company or organisation, you will also need to look for suitable candidates to fulfil the following specific roles. Without them, it would be significantly more challenging to develop a successful project.
Project sponsor
The project sponsor will be someone within your company whose role it is to approve the budget and essentially to fund the initiative. They may be someone within a department or even a chief officer of some kind.
Project champion
The project champion, on the other hand, is someone who will benefit from the implementation of your project. They may not necessarily be a sponsor or end user, but they will reap the benefits of your project’s success. Consider a head of a company department who will not actively use the product themselves, but whose subordinates need it to become more efficient.
Project stakeholders
Finally, a project stakeholder will be someone who not only knows and understands the business domain extremely well, but is keenly aware of the problem, knows exactly how things should behave and what types of things are permitted or not. They are essentially key participants in your project.
Consider, for example, that you cannot develop a good accounting system without someone from your accounting department, or perhaps even the head of accounting. Or alternatively, when deploying the final product within your infrastructure, your IT department would support these efforts. As such, they would need to ensure that it aligned with their expectations and requirements, and fully satisfied their specific policies.
The Project Scoping Phase
The next phase is putting together the scope of your project. This involves the steps outlined below:
Gather initial requirements
To ensure all future communication with your project participants is efficient, your project’s idea and vision should not just exist in your imagination. You may even get away with a short description of your key requirements. Yet putting together a number of essential artefacts will not only be useful when discussing project details with other participants, it may even prove vital when reaching out to developers.
Such artefacts will include:
- a project brief
- diagrams
- a high-level feature list
- wireframe mockups
Of course, there is no precise list of what information you need to gather before developing a bespoke application, but the more details you have — the better the chances of successful delivery. Many third-party vendors will also be able to assist you in producing these artefacts, should you require any help with business analysis, architectural or UI/UX design.
In any event, when talking to bespoke software development companies, it is important to communicate the following:
- What goals you would like to achieve in the project and why
- Who will be using the software solution and for what reason
- How you would like the bespoke product to work
- Your desired feature set.
Consult with everyone involved
By now, you probably get the sense that when developing bespoke applications, it is essential to consider the opinions of end users, stakeholders, project sponsors and anyone else who might be impacted by your project. After all, your project may be tightly integrated with the rest of your company infrastructure and thus affect other systems as well.
Document all requirements
There are various approaches to documenting requirements. While some may tackle these from a high-level outlook, others may choose to write user stories, divide functional and performance requirements into several requirement documents, employ Software Requirements Specification (SRS) documents or other types of formal project specifications.
Software Development Planning Questions
Once you are finally done with project scoping, you know exactly where you are headed and what types of features will be required to get there, then it is time to turn your attention to the software development project plan. In order to do this, you need to answer all the questions below:
1. Where will the software reside?
Should your bespoke software solution be server based, in-house or cloud service reliant (i.e. should it be hosted on on-premise servers or by a cloud platform like AWS or GCP)? Will it be hosted by a cloud infrastructure provider (e.g. Digital Ocean)? Bear in mind that for on-premise hosting, you will also need to consider whether you have the required resources for in-house infrastructure handling in addition to DevOps involvement. Note too that when it comes to cloud services, there could also be unexpected expenses.
2. What are the project constraints?
While everyone strives for quality, we are all at the mercy of the iron triangle of project management. This triangle represents the three main project constraints of time, scope and cost that can greatly impact your project’s success.
It is worth pointing out that because all sides of the triangle are connected, they will each have an impact on one another, so try to find out where this is a measure of flexibility (i.e. where a compromise can be made).
For instance, if you know that no matter what, your budget is $50,000 and you cannot afford to spend a penny more, in order to respond to external challenges, you would not be electing to increase the budget. Instead, you might choose to reduce the project scope or increase the time needed for the work to be completed.
Furthermore, there could be other project constraints as well, such as those of a technical variety. Say you require a certain technology stack but you do not possess the needed in-house expertise. You might not wish to move beyond your existing talent pool because it’s challenging to hire IT specialists. Consequently, make sure you become familiar with your own project’s constraints to work well within your limitations, and make room for the potential variables.
3. What is the right technology for the project?
When making this important decision, make sure you ask yourself:
- How much will using this technology cost?
- How easy is it to support it from a technical perspective?
- Do I have the right expertise for it?
- Is this technology mature and reliable?
- Does it satisfy my criteria and requirements?
- What are the long-term costs associated with this decision?
- Is this technology viable for a long-term project?
All of these questions will need to be answered, so it would be wise to seek the help of specialists.
4. How will the solution be integrated with other systems?
Integration with other systems will have a direct impact on both project duration and budget. So before you jump the gun, it is important to consider different integration models. After all, do those systems possess an open API? Will developers have access to it? Do you have to pay to gain access to it?
Below are just two possible scenarios:
- The API is proprietary. In such an event, you would have to pay the original vendor to gain access to it. You would then have to somehow provide the access to your developers so they can get to know the API if needed, before eventually beginning implementation.
- The system will send data to your existing solution. Should it do so, your existing system might become overwhelmed if it is not prepared to handle that kind of load. So think carefully about the potential impact and if your system will need to be modified, as this will probably require another team of developers who will have to do it by a certain date.
There are many other potential variables, so be sure to give integration the attention it needs.
5. Do you have a project charter?
While certainly not mandatory, it’s always good to have a project charter in place. This essentially is an elevator pitch for your stakeholders that should seek to provide a succinct explanation of all the main elements of your project. When done correctly, it can help you obtain approval and correct your direction of travel if needed. Here is an interesting guide on how to write your first project charter.
6. Do you have approval from company management?
Don’t forget: before agreeing to any sort of development, you will have to obtain approval from your company’s management to ascertain that they are pleased with the project and are prepared to give the go-ahead for the funding.
UI/UX Design
As a general rule of thumb, everything is easier when it can be visualised. This is also true when you start a bespoke dev project. So when sharing key concepts with your project sponsors, be sure to utilise rapid prototyping to show them what the solution will look like when ready. This will enable you to highlight all the important benefits in relation to your current manual operations or processes. Sketches and mockups will also be useful when requesting quotes from developers and designers, as they can avoid surprises with a changing budget. And finally, rapid prototyping is an absolute must-have before actual development work begins, as it will enable developers to choose the best technology and understand the user-system interaction. In summary, the sooner you prepare these mockups, the sooner you can present them to developers, which will lead to more accurate estimates and a better choice of software technologies.
How to Choose the Right Software Vendor for Your Company
By now, you should be ready to make the big decision. One way to do this is to search for top service providers using a specialised platform like TopDevelopers.co, who not only rank software development firms based on a variety of different factors, but will also provide invaluable feedback. Once you’re happy with your initial selection, it is time to whittle down the contenders. Let’s begin with a project brief.
Write a project brief
As long as your project scoping stage has been productive, you should already have enough information to put together in a project brief — important details about the project that are intended for your software vendors. Essentially, this should help them to understand not only your project, but also its niche and your company’s requirements. A project brief can also help vendors decide if it’s the sort of project they would like to be working with, which will avoid wasting time with providers who were never really a good fit for your project.
Identify the software development team — in-house or external?
Presumably, this part of the software development process will be fairly straightforward, but make sure you’re aware of the type of developers you will be partnering with, be that an in-house or external team. If you lack the in-house talent and external expertise will be needed, then how exactly do you see this happening? Would you prefer to bring in some external experts (aka Team Augmentation) or to outsource the project entirely?
When deciding to go with an in-house software development team, make sure you book required resources well in advance and that your teams will be available when needed, in accordance with your internal processes. Consider too if you would like to hire additional specialists as a replacement or extension in the team.
On the other hand, should you decide to go with an external team of developers, you will have to follow a procurement process:
If your company already has some form of procurement, then you should task them with sourcing suppliers. This search for candidates may be done in a few different ways:
- Run a simple tender to identify a short list of suppliers before having another round to identify the best possible fit
- Other forms of supplier selection on a purely quotational basis.
In any case, in addition to expertise and trustworthiness, remember to analyse other factors such as location and company size as well, as you may not wish to work with a smaller company, preferring those with more established specialists.
Evaluate commercial offers
Your prospects should also create a work breakdown structure (WBS) and submit to you their commercial offer. In it, they should explain:
- How long your project will take from their own point of view
- What is important to consider from a technical perspective
- How much money they believe this will cost you.
Moreover, the offer should include a project roadmap, a step-by-step plan for developing and delivering products that will ideally show all stages of the project in addition to important milestones. This will serve as an essential summary of how they see your project’s implementation that will enable you to quickly compare the delivery roadmaps of different suppliers. Bear in mind that when comparing roadmaps, it’s not just about whether or not you like the execution timeline that they have chosen for you, but whether you think those dates are achievable and if they match your organisation’s schedule.
Compare deliverables
Remember to also examine deliverables, as these can greatly vary from one supplier to the next. Make sure you choose the suppliers that fulfil your objectives.
Determine the definition of “done”
Though it may sound daft, you need to make sure that both you and your software vendor will share the same understanding of when the project is finished. This is not about warranties, but about determining that elusive line where the supplier’s obligations end and your own responsibilities begin. So in practical terms, when is the project going to be completed and what exactly should then happen next? Who will be handling the actual deployment? Who is responsible for setting up monitoring so that it continues to work in production? And who should deal with backups for this particular solution?
Non-linear criteria to consider
Lastly — in no particular order — when planning to start a bespoke dev project, here are some other miscellaneous items to consider:
- Terms and conditions. There could be some important differences here.
- Bug fixing & support. What is the potential vendor’s stance on the matter?
- Knowledge transfer. Do they provide this knowledge transfer to you? Can you be sure that your in-house specialists will be equipped to support your application after delivery?
- Warranty. Does the vendor provide one? What are the conditions attached to their warranty?
Finalise Your Project Roadmap
From here, based on the vendor’s proposed roadmap and project plan, your company will need to finalise a project roadmap of your own. After all, only you know that, for example, you have hired designers, or have another team working on a third-party system which will be integrated into this product. Essentially, therefore, you need to align the proposed project plan with all your other plans that could yield an effect on it. Alternatively, however, if you are happy with the vendor’s roadmap, you can simply go ahead and approve it.
Sort Out the Legal Bits
And finally, to conclude our guide on how to start a software project, make sure you study the contract at length before signing it, as these can also vary widely in business software development and you wouldn’t want to be caught off guard. This is without a doubt one of the most important best practices when working with bespoke developers — or any other vendor for that matter.
Time to Start a Bespoke Dev Project!
Understandably, the software development environment can be fraught with stormy seas. Yet once these steps have been taken care of and you are happy with your negotiated contract, then you are finally ready to set sail with your project! You can now sit back and let the software vendor bring your vision for the product to fruition. Just remember to at all times stay close by and be prepared to steer the ship when needed.
