Custom Software Development Process and 7 Mistakes to Avoid

Initial Discovery, Research & Estimation

We listen to understand what you want to build, what features your product should have, and what bottom-line results you want.

• Requirements Gathering Arrange a call with our business analyst so you can describe the product features.
• Tech Solutions Research We look into your business idea and business processes to identify the current and most suitable tech solutions.
• Rough project estimate Get an idea of the potential expenditure involved with a project deliverables.
• Partnership Agreement Establish relationships for completing a project over time, IP transfer, and other terms.

Workshops & Planning

The results-driven design thinking approach we use at SoftKraft is a catalyst for iterative product development. Get ready for an intense design workshop that will clarify your business idea and help us build a much better product.

The Product, Design, and Engineering Workshop allows us to come up with the detailed documentation, wireframes, and mockups of your project.

We agree on the initial architecture & tech stack, set the milestones for the business and development roadmap, set the dates for upcoming Sprint Demo’s & agree on a time for Daily Standups.

Development Sprints

We use a structured & repetitive process that is divided into smaller parts - sprints. Each iteration covers a part of the project scope that is deliverable in a short and controllable period of time. Each sprint ends with a demo of a working part of the product.

The implementation process includes:

• User Story Tasks with a clear Definition of Done
• Live Design Sessions with the Decision-makers
• Staying updated by Running Daily Standups
• Voting Story Points & Giving Task Responsibility
• Code & QA Peer Review included in the Process
• Running Live Updated Documentation
• Management Tools for Tracking the Progress
• Tracking the Story Burndown Chart
• Presentation of the Delivery at Every Demo

Stabilisation & Release

During this stage, we focus on perfecting every area that makes the final product meet the Users' expectations. When the stabilization stage is over and we have positive feedback from the first users we can deploy the first version into the production environment.

• Change Requests We add last touches & implement small things that can have a big impact on how the user interacts with the product.
• User Tests We run a UX audit & usability interviews with the first users. We analyse their behaviour using tools like GA or Hotjar.
• Performance Tests We test efficiency of the implemented functionality & go through the project test checklist.
• Staff Training We teach your team members how to admin and use the product in a proper way.
• Documentation Hand-off We give you all the know-how and the documentation behind your product.

Support & Aftercare

We can monitor the performance, we can analyze how the users interact with your product and we are ready to fix all the issues based on the SLA or a different arrangement. Our Project Support Framework is Flexible.

Depending on the client & project needs, we set the rules for support and maintenance. We set the error handling rules, issues priorities, time of our reaction, and the amount of time of our custom software developers that we should book monthly.

Building wrong features and unnecessarily complex solutions

If you’re about to invest in custom software, you have high hopes for what it can do for your business. When you can make "anything you can imagine", you can get off track and spend a lot of money on the wrong things.

To avoid costly mistakes, it is important to allow the interaction between the end-users and the product to happen in the early stages of the process of development. Staying on the same page with the end-users is vital for the whole process and the product itself.

By creating a prototype, people that are involved in all the stages of the development process can better convey their vision. Prototyping is cheap and works better than just describing the vision or ideas because it helps to visualize them and answer most of the bothering questions about functionalities.

Delaying end-users validation and feedback until you have a complete project

Often, initial assumptions about your needs or your end-users needs will be incorrect or incomplete, even when you have done prototyping with end-users. You need you keep validating your project.

The best way to do that is to take Minimum Viable Product approach: build the smallest thing you can, launch it as soon as you can do so responsibly, and adjust or add more features based on feedback.

Exploring unfinished software can be difficult—a bit like walking around a construction site. You may need to be mindful of holes in the floor. But it’s much easier to catch problems and avoid costly surprises or issues by poking around your software early and often.

Often, even MVP takes weeks or months to build. That’s why it is essential to have the development team demo working software to you at a minimum interval of every two weeks. This goes well with scrum methodology, where team commits at the beginning of a sprint (usually two weeks long) that they will deliver particular functionalities within a fixed period of time.

At SoftKraft, we deploy working software to a staging server where you can review it, either before or soon after that demo. We also prepare a list of features that were completed, so that you can go in, examine the features for yourself, and make sure that they meet your needs.

Making all crucial decisions as soon as possible

Decisions made too early in a project can be hugely risky. Early decisions often result in work that has to be thrown away. Even worse, they can have crippling and unavoidable consequences during the entire lifetime of the project.

This doesn’t mean that we don’t make decisions at all. It means that using an iterative development cycle and the "amplify learning" concept. It allows you to gather requirements and facts quickly, and then make a decision, rather than deciding early without all the information needed.

Keeping decisions about features and the development of those features close together helps to ensure that the right features are delivered, and it leaves less room for change. This results in less waste. This waste is defined as anything that doesn’t provide the customer with any value. In a software world, those can be things such as:

1. Code that is written but not used or not providing any benefit

2. Documentation that is not relevant or required

3. Waiting for requirements or information

4. Unclear or constantly changing requirements

5. Starting more than can be completed, partially done work

6. Defects and quality issues

The iterative process of learning and continual improvement is important part of identifying waste. It also gives you time to explore the different options in more depth and experiment, helping to come to the right solutions.

Not leveraging off-the-shelf software solutions

When you’re building custom software, there may be ways to economize on the cost by using external software solutions, APIs integrations, or pre-built components for portions of your project. You can save tens of thousands of dollars with clever reuse of off-the-shelf components and solutions.

Sometimes an off-the-shelf tool meets 90% of the requirements, but the cost to reach that final 10% is exponential. In those situations, you should reconsider that extra 10%. If those requirements are the market differentiator, then, it makes sense to pursue them. However, if they aren’t truly important to the product, being a little flexible with your business requirements can save significant cost and time.

At SoftKraft, we like to leverage pre-built components, API integrations and external software solutions. We focus on delivering value, not lines of code. Contact us to learn more how we use off-the-shelf solutions to build custom software faster.

Putting full control over the project scope outside the team

You can make all the decisions and tell the developers what to do, and the developers go away and do it. However, if you want to deliver your project efficiently, in a way that achieves maximum productivity with minimum wasted effort or expense, you should empower your team with more decision-making ability through lean software development methodology.

At its core, lean is a business methodology that promotes the flow of value to the customer through two guiding tenets: Continuous improvement and respect for people. Lean is both a philosophy and a discipline which, at its core, increases access to information to ensure responsible decision making in the service of creating customer value.

Lean is a never-ending elimination of waste; it is committed to total customer satisfaction, total commitment to quality and total employee involvement. With lean methods, the software development team is able to do the work that they need to do, make suggestions and recommendations to leaders and managers, and make assessments, which are all based on their own experience.

Lean methodology helps to motivate and convince each team member that there is a more important goal or purpose that they are working towards. The goal should be clear, achievable, and relevant to the team and the work being done.

Not providing clear acceptance criteria for each feature

Acceptance criteria are a set of predefined requirements that must be met in order to mark a software development task as complete. It clearly defines the scope, desired outcomes of, and testing criteria for pieces of functionality that the delivery team is working on. The process of creating and agreeing on acceptance criteria itself is also an invaluable communication opportunity between developers and product.

When you define all of your desired outcome before development begins, you help promote alignment and shared understanding. This understanding helps reduce the likelihood of surprises down the line. Here are a few traits of effective acceptance criteria:

Acceptance criteria should be testable. Since these requirements help formulate the definition of done for your engineers, they need to be easy to test. And the results of these tests must leave no room for interpretation, like straightforward yes/no or pass/fail results.

Acceptance criteria should be clear and concise. You aren’t writing comprehensive documentation here. Keep your criteria as simple and straightforward as possible.

Everyone must understand your acceptance criteria. Your criteria are useless if your developers can’t understand it. If you’re unsure about whether something is clear, take the time to ask and make adjustments until things are clear.

Acceptance criteria should provide a user perspective. Acceptance criteria is a means of looking at the problem at hand from a customer’s standpoint. It should be written in the context of a real user’s experience.

At SoftKraft, team leaders are software engineers with vast experience. They are ready to help you learn how to write clear acceptance criteria that will both speed up development and ensure that the features you get work as expected.

Concentrating too much on individual features

Software solutions are no longer developed as a standalone system. The integrity of a system is important and can be explained in two methods – conceptual integrity and perceived integrity.

Conceptual integrity means that the system’s individual components work well together as a whole. It should be flexible, maintainable and efficient. The design and usability should be consistent throughout, and it should reflect the requirements and the business problem it is trying to solve.

Perceived integrity represents the way that the system is being observed or perceived by the users. This includes everything from the way it operates, how it is delivered, maintenance, and relation to business problems.