Why should you use an agency to build your software?

In today's fast-paced and highly competitive business environment, companies need to continuously improve their operations and processes to stay ahead. One way to do this is by leveraging technology and software to automate and streamline various functions. However, not all businesses have the in-house expertise or resources to develop and maintain software solutions on their own. This is where software development agencies come in - they offer a range of services to help businesses create, implement and maintain software solutions that meet their specific needs. In this blog, we will discuss the benefits of using a software development agency.

Cost-effective

One of the biggest advantages of using a software development agency is cost savings. Hiring and training an in-house team of software developers can be costly, time-consuming, and risky. By outsourcing software development to an agency, businesses can save on salaries, benefits, training, and infrastructure costs. Surveys show the cost-effectiveness of using an agency in low cost software destinations such as Bangladesh but even if you are not going offshore using an agency close to you will bring down your costs by reducing your HR commitments along with the cost of operation.

Expertise and Experience

Software development agencies have a team of experts who have extensive experience in developing software solutions for different industries and use cases. They have worked on various projects and have the necessary skills, knowledge, and tools to create effective solutions quickly and efficiently. They also keep up-to-date with the latest trends and technologies in the industry, so businesses can benefit from the latest innovations and advancements. By hiring an agency in essence you are getting access to their entire skillset and expertise on a need basis, a great example is how we help our software customers with a design team when they need to create visualization of their ideas - the design team comes in for a short time to turn the ideas into mockups and specifications that the software team can use as their guide. The cost to the clients is minimal, yet the benefit is a dedicated design and product team that only giant companies can afford.

Faster Time to Market

Software development agencies have streamlined processes and workflows that enable them to develop and deploy software solutions faster than an in-house team. They have experience working on different projects and can quickly adapt to changing requirements and timelines. This means businesses can launch their products or services faster and gain a competitive advantage.

Scalability

A software development agency can scale its resources and expertise based on a business's needs. This means that as a business grows, the agency can provide additional resources and support to meet the increasing demands for software development services. Similarly, if a business needs to downsize or reduce its software development needs, the agency can adjust its resources accordingly.

Focus on Core Competencies

By outsourcing software development to an agency, businesses can focus on their core competencies and strategic initiatives. This means that they can allocate their resources and attention to activities that are critical to their success, such as product development, marketing, sales, and customer service. Software development becomes a supporting function rather than a core competency.

Using a software development agency has many benefits for businesses looking to develop custom software solutions. It can help businesses save on costs, access expertise and experience, launch products faster, scale resources as needed, and focus on core competencies. Businesses should carefully evaluate their software development needs and choose an agency that can meet their requirements, deliver high-quality solutions, and provide ongoing support and maintenance. By doing so, they can reap the benefits of technology and stay ahead of the competition.

Outsource with confidence: 7 Essential Practices for Software Development Success

In the fast-paced realm of technology, the decision to outsource software development can be a game-changer for your business. Whether you're brimming with a brilliant app idea or seeking to revamp your existing one, outsourcing can provide the expertise and bandwidth you need without the hassle of managing an in-house development team. Bangladesh, where we are based is a major hub for outsourced software development projects, and there are really good reasons to outsource here. So over the past 20 years of working with companies from all over the world, we’ve picked up some good tips and tricks about how best to run an outsourced software project. Before embarking on the quest for the perfect development partner, it's crucial to familiarize yourself with the best practices that can shape a successful outsourcing journey. Here are seven key principles to guide you through the process:

1. Define Your Reasons for Outsourcing

Before diving into the outsourcing pool, introspect on the reasons driving your decision. Ask yourself, "Do I really need to outsource?" Clearly identify the factors pushing you towards this choice and create a reference list. This introspection will serve as a compass, steering you through the outsourcing process, and aiding decision-making. Ensure that your project is suitable for outsourcing, particularly when specialized expertise, additional support, or time constraints are significant factors. A great read along these lines is this post about finding the right balance for outsourcing parts of your software projects.

2. Choose the Right Partner

Selecting a reliable outsourcing partner is paramount to the success of your project. Look for a company with a stellar reputation and a proven track record of delivering results. While peer recommendations and reviews are invaluable, delve deeper into compatibility. Assess whether the partner's work culture aligns with yours, and if their working hours and communication methods suit your preferences.

3. Look Beyond Cost

While cost efficiency is a driving force behind outsourcing decisions, it should never be the sole consideration. Prioritize the quality of the end product during the selection process. Ensuring that you receive a high-quality solution is essential, even if it means investing a bit more upfront.

4. Thoroughly Scope Your Project

A detailed project scope is the cornerstone of successful outsourcing. Use this as a trial project if you're in doubt about a potential partner. Provide a comprehensive project scope to align everyone's expectations and establish a procedure for handling additional work outside the initial scope. Prevent project delays caused by incessant feature additions and requests.

5. Establish Robust Communication Channels

Effective communication is the backbone of any successful outsourcing venture. Implement strong communication channels to facilitate seamless interaction with the development team. While multiple channels like Slack, email, messengers, Skype, telephone, screensharing tools, and issue trackers may be available, designate a primary channel for efficiency and clarity.

6. Stay Actively Involved

Outsourcing doesn't imply a hands-off approach. Stay engaged with the development process by checking in on progress regularly. Understand the team's requirements for resources and provide necessary input to keep the project on track. Take ownership of the process for optimal results.

7. Embrace Task Management Tools

Regardless of your project's scale or complexity, task management is non-negotiable. Implement a project management or task management system to monitor development progress. This helps you track tasks, understand the pace of development, and identify potential roadblocks in collaboration with your outsourcing partner.

Outsourcing software development can be a strategic move for meeting your company's needs, but success is not guaranteed without a thoughtful approach. This list serves as a foundational guide, emphasizing the importance of selecting the right partner and establishing processes that enhance the likelihood of successful outsourcing. Explore our additional tips and tricks for selecting software vendors to further refine your outsourcing strategy.

Managing a multi-cultural remote software team

Remote work is the new normal, and managers need to be prepared to lead their teams in this new environment. And in today's globalized world, multicultural teams are the common remote teams. Cultural diversity is common in onsite teams too but the issues of miscommunications because of cultural issues are much more complex in remote teams. With the rise of remote work and the desire for flexibility among younger generations, managing a team from different cultural backgrounds has become one of the biggest challenge for managers. And this is an essential skill that all managers are picking up.

Since Kaz is a software development agency based out of Bangladesh and we work mostly with software companies based in the US or Europe. So the very nature of our work leads us to the remote cross cultural issues. And this not a new thing for us because of the recent rise of remote work. We’ve been participating in remote software teams for the past 18 years, and over that long time we’ve probably seen all the things that can go wrong in such cross culture, cross language teams and have devised strategies that solve those issue (or at least reduces to chances of them arising). We’ve also come up with a little poster for expressions in English that doesn’t translate well, that we sometimes give to our customers’ project managers as a cheat-sheet! So, today’s post is a summary of some of our best tips around this and that useful “cross culture expressions to avoid cheat-sheet”.

Understand that there is problem

This is important. Specially in the software world. We sometimes hear things like: “At the end it’s all code, and the language of code is the same so there will be no problem”. Although at the fundamental level that is very true, but to get to that stage of work and collaboration the remote teams still have go through layers of communications. That communications is typically in a language that isn’t a first language for at least one side and sometimes for both sides. And that’s where the start of the problem happens, and layer on top of that the cultural difference and the fact that cultural context changes the meaning of many expressions and mannerisms - you have a problem. So it’s vital for software managers to understand that there is a problem and it will need active strategies and process to solve that problem.

In this context, it is essential to recognize that cultural differences can lead to misunderstandings and conflicts. As the speaker in the video explains, even seemingly simple things like expressions about time can have very different meanings in different cultures. For example, in some cultures, "just now" might mean "in a few minutes," while in others, it might mean "sometime in the future." Without understanding these differences, miscommunications can easily arise, leading to frustration and conflict.

Create culture awareness in the team

To address this challenge of cultural difference and the need to work around such difference, it is important to invest in cultural awareness and sensitivity training for managers and employees. This might involve providing resources such as books or online courses on cross-cultural communication, as the speaker in the video did. It might also involve hosting workshops or training sessions led by experts in intercultural communication.

One key aspect of this training should be the importance of context in communication. As the speaker explains, even when two teams are using the same language, differences in context can lead to misunderstandings. For example, a phrase that might be intended as a compliment in one culture might be interpreted as criticism in another culture. Understanding these differences requires a deep appreciation for the cultural norms and values that shape communication styles in different parts of the world.

Create an environment of trust

Another important aspect of managing a multicultural team is building trust and rapport among team members. When people come from different cultures, they may have different expectations about how to build relationships and establish trust. For example, in some cultures, it may be important to spend time getting to know someone on a personal level before discussing business matters, while in others, business may be the focus from the outset. Understanding these differences can help managers to build stronger relationships with team members and foster a sense of camaraderie and trust.

We’ve written extensively about this in the past, as we feel that this is one that that makes thing much simpler to solve cross cultural issues. Some of our tips can be found in this article about how to build trust in your remote team by team gelling or this one about creating the right team culture for companies with remote teams.

Find what works the best for you

It is important to recognize that managing a multicultural team is not a one-size-fits-all endeavor. Different cultures have different expectations around communication, hierarchy, and decision-making, among other things. Effective managers must be able to adapt to these differences and find ways to accommodate the needs and preferences of each team member. This might involve using different communication tools for different team members, or adjusting work schedules to accommodate different time zones.

Careful about what expressions you use

It's important to be aware that expressions that you might use in your language or cultural context might not be understood at all or even worse understood with the opposite meaning by your remote team. It is vital for team managers (and team members) to consider cultural differences when communicating with people from other backgrounds. It's also a good idea to clarify the meaning of an expression if you think it may be misunderstood. Here’s our list of common English expressions that just doesn’t cross the language and culture basriers well. We call it the expressions to avoid cheat-sheet!

"Break a leg" - This one never works. In most non-English cultures, wishing someone luck by saying "break a leg" is considered bad luck or even offensive. Actually if you think about it really weird that this expression has the meaning it has, here’s the Wikipedia post giving it’s history.

"Bite the bullet" - This expression means to endure a painful or difficult situation, but in some cultures, the literal meaning of biting a bullet can be confusing or offensive.

"Spill the beans" - This expression means to reveal a secret, but in some cultures, the idea of spilling beans may not make sense or may be seen as wasteful. I remember once one of our customers used this expression in the context of asking his team not to reveal software features anyone and the look of confusion in the team was very interesting!

"Piece of cake" - This expression means that something is easy, but it almost always fails to translate well.

"Going Dutch" - This expression means to split the bill, but in some cultures, the idea of going Dutch may be unfamiliar or seen as impolite.

"Skeletons in the closet" - This expression means to have secrets or embarrassing information, but to someone not used to the expression the idea of keeping skeletons in a closet would not make sense at all!

"Costs an arm and a leg" - This expression means that something is very expensive, but in some cultures, the idea of comparing something to body parts may be seen as distasteful.

"Cat got your tongue?" - This expression means to ask someone why they are not speaking or responding, but this one never works either for obvious reasons.

"Let the cat out of the bag" - This expression means to reveal a secret, but the idea of a cat being in a bag may not make sense or may be seen as cruel for non English speakers.

Leadership in software development

I was recently reading an interesting post about various kinds of leadership styles in the business world. The author tried to distill the styles into the following:

• Autocratic Leadership - my word is only word good or bad style of a leader

• Authoritative Leadership - follow me (better version of the autocratic if the leader has a clear vision)

• Pacesetting Leadership - driven leader who sets a high standard and pushes people towards that standard.

• Democratic Leadership - consensus driven

• Coach-Style Leadership - a style that focuses on mentoring the team towards perfection

• Affiliative Leadership - people and their needs first approach towards work

• Laissez-Faire Leadership - hands off, I trust you to do the job style

Pretty exhaustive list, but while we are at it, I’d add some weird ones I’ve come across in my working life too:

• Bureaucratic Leadership - follow the procedure whatever the case style

• Transactional Leadership - tit for tat style, where your life gets better if you perform better. Money money money sort…

And of course the infamous

• No Leadership

This is great, although I would think in reality any particular leadership is a mixture of style. But I would also agree that in general there is a “style” that dominates in everyone. So the big question that comes next for us software people is:

What’s the best style for software teams?

There is no fixed answer to these type of questions except maybe the boring ones that start with “depends…”. But I’ll not go with the boring ones and try to answer this in a very specific way with our experience at Kaz Software. With more than 17 years under our belt, making and delivering software and more importantly surviving :) I’d say our way is a good answer as any. So much so that I’d say Kaz’s way i the only right answer and any other answer is wrong.

So here goes…

The answer is (imagine atmospheric background music here): Intrinsic Motivational Leadership

OK, that one isn’t in the list above and it’s kind of a made up name, but let me explain.

Intrinsic motivation is the motivation that comes from within. This is a opposite of the extrinsic motivation that is usually money or status. A leader who can create this motivation in his or her team is the only kind of leader who will excel and that software team will be the best at what it does. A leader with this style of leadership follows two goals:

Goal 1: Create a jelled teams

Such leaders know that in the business of software development teamwork is the highest priority. That is the only way to get reliable and reproducible results from a team. To create cohesive team that feels like a family is the biggest goal for such a leader. A team that feels like a family has a specific identity, specific way of doing things and saying things. All these together creates sense of loyalty and commitment towards the common goal at hand - be it the challenging deadline or fixing the impossible bug.

“Google users trust our systems to help them with important decisions: medical, financial and many others. Our search results are the best we know how to produce. They are unbiased and objective, and we do not accept payment for them or for inclusion or more frequent updating. We also display advertising, which we work hard to make relevant, and we label it clearly. This is similar to a well-run newspaper, where the advertisements are clear and the articles are not influenced by the advertisers’ payments. We believe it is important for everyone to have access to the best information and research, not only to the information people pay for you to see.”

— Google's 2004 founders' letter prior to IPO

It helps if the company’s long term goals are something to be proud about. A great example is Google’s “don’t be evil” which has been an unifying slogan for Google’s teams. Although it’s been slowly phased out when Alphabet formed.

Similarly Apple employees have almost fanatical following and identification with the company’s goals and aspiration with the famous slogan of “we are against totalitarianism”. A classic Steve Jobs move which started with the Mac ad in the 1984 superbowl directed by none other than Ridley Scot (of Alien fame). If you haven’t watched the ad, it’s a must…

So a leader whose goal is the intrinsic motivation, will need to do something that to creates an identity which leads to that jelled team goal.

Goal 2: Make information available

A software team is by it’s very definition a group of smart individuals. Software companies invest the biggest on their HR cost and that is all because of the smartness of individual members of its teams. A motivational leader knows that the best way to lead is not to rely on his or her own brain but rather to rely on the collective smartness of the team at hand. And to make that possible the leader has to do everything to make all information needed to make a decision available to the team. Thus, hiding some facts that are only available to the “management” is not an option for such a leader. She has to work with different parts of an organization to bring relevant facts and information out in the open for the team to decide what the next step is.

To achieve this goal a leader has to convince the management that openness is the right way forward - not an easy task. It’s difficult and sometimes almost impossible for business leadership to reveal the innards of an organization. A project that is running of funds, a customer who has negative feedback about a team, a marketing venture that lost a lot of money, etc. are ugly facts of running an organization. Hiding such information from the teams lead to statements from leaders like “I know things that you don’t know…” - which just doesn’t lead to intrinsic motivation goal. It also makes it impossible for smart software teams to come up with decisions that are based on facts and data. So a motivation driven leader will have to do all in her power to make such information available to the team and then empower the teams to make decisions. Collaborative decisions coming from agreement from the team leads to the most effective decisions and a leadership that focuses on such a strategy is always a winner in software organization.

I’ll leave today with that great video of the 1984 superbowl ad that Apple made… always a fun watch. While you are watching it keep remembering that this is an ad for a computer!

Making your software: Step 5 - Select a development partner

Priya, our fictional software entrepreneur from the previous chapters on this series has a dream to make “Designly” a software platform for interior designs. She has followed our suggestions on writing down her features in the specific format that software developers love as step 1 in her journey to make her software. She has then gone through the methodical approach of finding possible software developers using a simple yet effective process using the method laid out in step 2 - find software developer She has then followed through to step 3 - to get ballpark estimates that gave her the information to budget and create a financial plan in step 4 - budgets and funding. Now she has the all the groundwork done with a good plan to move forward. Now is the time to roll up the sleeves and get into action - the actual software development of the product. And the first step in the action is to select the software development company that will do the job for her. From her previous steps she has nice and short list of good vendors, she just needs to make up her mind in this step to pin down the one she wants.

Part of the selection process is to setup the contracts. The actual legal contract is important, but at the end secondary - since no legal write up can replace a good working relationship. It’s extremely important to setup an operating process - decide how the project will move forward, how you’ll see the results and give feedback, the timeline, etc. The non-disclosure agreement (NDA) is Priya’s protection for the idea about the product as the software company will require her to go over the details of her idea before they can give a final costing they can commit to. There are variations to this plan, but this is typically the path most companies take.

The NDA

The NDA, short for non-disclosure agreement is Priay’s protection of her idea. For the software company to brainstorm and finalize her business idea to fit with a practical software within the limits of budgeting, they need to know in detail about Priya’s idea. The NDA provides protection to Priya in the case where the vendor doesn’t just steal her idea and builds it themselves. In the software world typically ideas are the common thing, implementation is the hard part, but still the NDA provides a much needed peace of mind for the two parties to discuss without fear.

A good NDA will help both sides. So there are typically time limits to the non-disclosure, also well defined definitions for scope about information. It’s obviously vitally important for Priya to protect her business secret and make sure that the vendor does not go away and make it product like hers. On the other hand a typical software vendor will be working with a multitude of customers, some within the same business area as Priya. So the vendor would also need protection from an over restrictive NDA that exposes them risk of breach even though the situation may be just a case of working on similar ideas for different clients. This balance of protecting both sides can only be achieved with scope and clear definitions of what constitutes a secret and what doesn’t.

For most contracts it’s best to use the help of a legal expert. However, NDAs are so standardized these days that Priya can get by using a template from the internet. Here’s one that we like: Free software NDA template but a google search will land Priya many other good ones. Note how the NDA has very clear definitions of information, exclusions and time periods.

Work plan

The next big thing in this phase is come up with a workplan - how the software developer will work with Priya to create the product. The workplan doesn’t have to be very detailed like a project plan, that will come in later when the software mockups are done and the software developer has enough information to create a milestone based project plan. The workplan is more a discussion and an agreement (maybe a verbal one) about how the next few steps will be done and then how the software development itself will be done.

Every software development company has it’s own way of doing things. There are some broad similarities, but the actual working plan is very specific to a software company. So it’s important to clarify that plan so that Priya knows what to expect and also the vendor gets to know about any concerns or timeline pressure that Priya might have. And it’s a good idea to do it at this early stage so that an red flags are spotted early and fixed (hopefully) before any side has made any significant investment in time and money.

A typical work plan (something we at Kaz follow for example) is:

1. Create team for project with clearly identified responsibilities and contact channels (say skype/phone/email/…)

2. Do a series of meetings go over requirements and create wireframes for the main features of the product.

3. Once the wireframes are finalized, create colored mockups to design the exact look of the final software.

4. Create a detailed project plan with timeline and delivery milestones.

5. Finalize the pricing and create a software development contract (unless this was done before).

6. Setup of shared issue tracker.

7. Setup of shared staging environment where client can see product on every build (usually daily).

8. Weekly (if not daily) status meetings and early feedback sessions.

9. Development and delivery at milestones.

10. Feedback sessions at delivery milestones.

11. Demonstration of key delivery of the product with larger groups on both sides.

12. Pilot phasing/Quality assurance sessions/UAT/etc.

13. Deployment on live infrastructure.

14. Support for live system.

15. etc.

End of step 5, Priya will have a software developer finalized and have a clear idea about the process that will get her the software application she wants to build. Now comes the fun and exciting part of actually building the software! It may feel like Priya is taking a lot of time to get to this stage, but remember that selecting the right partner, having the budget planning and having a realistic idea about the process is the only way to successful software product. Any shortcuts here could prove to be extremely costly down the line with time, effort and money spent on something that is not the product. So it is vitally important to go through the motions and get to this stage with confidence.

Making your software: Step 4 - Budgets and funds

Priya, our fictional software entrepreneur from the previous chapters on this series has a dream to make “Designly” a software platform for interior designs. She has followed our suggestions on writing down her features in the specific format that software developers love as step 1 in her journey to make her software. In step 2 she went over strategies to find a software developer company who will turn her dream into reality. Then she gets good ball park estimates for making the software in step 3. Now that she has some numbers she can work on her next challenge of budgeting and financial planning for the software development.

Software development can be expensive, so a proper budgeting and financial planning is essential to make your software and launch it successfully.

Phases of software launch

There are several distinct phases in getting a software product to the market. These phases actually go way beyond the obvious software development and sometimes the founders don’t really realize all the steps and runs into difficulties with finances when that step happens. Here are some of the phases and what a founder should expect from a budgeting and finance point of view on such phases.

Design and planning

Every software product has a significant design and planning phase. If you cut this phase short you end up a poorly designed software that is hard to use or a software that took a lot more time and money to build because the developers just didn’t have enough guidance on what to make. So it’s essential to invest on the design phase. If money is tight, as it is on most startups, this phase can be less elaborate than what textbooks suggest about design and planning of software but it still needs to have some basic things done. The top focus should be a set of “mockups” of the software interfaces. These are pictures of the software screens as the user goes over common or most used features. If money is seriously short, these mockups can be just black & white rough sketches called wireframes, but that’s the bare minimum that must be done.

Typically this phase will require 10 - 15% of your total budget for the software.

Development of the MVP

This phase is the actual software building phase. MVP stands for minimum viable product and we’ll go over the concept of MVP in a separate post. But basic idea is simple: find out what is the minimum set of features that will sell the software and make that first and launch with it. Here’s good video about MVP..

Typically as founder should plan for 40 - 50% of her total initial budget for the MVP.

Launch and marketing

The launch of the product by itself is time consuming and can come with unexpected costs. The developers may request for server certificates, special cloud setups, software licenses that a founder may not have budgeted for. On top of that the launch process itself takes developer time which adds to the costs.

The marketing is obviously a huge area to think about when you are launching a product. Nothing sells without proper marketing.

Typically launch and marketing should be around 20-30% of total initial budgeting, but note that this is one area where it’s very product specific. If a software is planned to be something based on a huge number of users then marketing itself can take up more than half of the all the money spent in a project.

Releasing the updates

The biggest mistake that founders make is not factoring in the costs of making changes to the software AFTER the launch. These changes are usually the make or break between a software that people use and one that goes into the software graveyard. After all, only after a launch does a founder really get to see what works and what doesn’t, what her users are using and what they are asking for. Based on these real data points a founder has to adapt the software, modify it or fix the bugs to quickly launch a new version (usually a series of new versions) that adapts to the need of the market. This process is iterative, it’s usually time and effort consuming and thus it’s expensive. Not budgeting for this phase means the software never had a chance to fight it out in the market. So it’s absolutely essential.

Typically a founder should budget at least 15-20% of her initial funds for this phase.

Maintenance

Maintenance is the phase of managing to keep the software live over time. This may involve bug fixes time to time, maintaining the servers, updating various components as new versions of the OS or other software is released or new security patches are put out. For mobile apps this means the continuous effort to keep up with the new versions of OS that Apple or Android guys are coming up with, each having the potential to break your software.

A founder should budget for at least 2 years of maintenance after launch in her initial planning. Very much a product specific thing, but typically over 2 years it would take up 15 - 20% of the overall costs.

Payment strategies

When the founder is planning for financials of a project there are certain strategies she can adopt for the funding and the payment to the developers. These are general tips, after all, as each project is different with it’s own sources of funding, own specific situations of payments. Here are two strategies that works well for startups.

Milestone based payments

Setting up a payment schedule with the developer based timed milestones is great for both sides. For the founder it gives certain dates where she needs to make the money available, it also gives are a quantifiable way of seeing what she is getting before she does the payments and of course more solid commitment from the developers about the dates. For the developers it’s a good way of splitting up a bigger software project and getting paid as they build it. It reduces their risk by not lumping everything up for a big payment at the end.

Phased development

The phased development strategy is where the founder just makes her final product over a set of phases. Each phase has it’s own launch, marketing and payment. This way the founder can get the product out in smaller steps, judge the market as she goes along and only commit to more payments if she sees the demand. For a developer too it’s is a good way of splitting a large project up and getting paid early. But note that if the phases are too small this might be impractical for the founder and the developer as the costs of starting and stopping the project in each phase can be a big overhead.

OK, that’s it for today on this series on getting your software made. I’ll be back soon on step 5 soon about finalizing a software partner to get software made.

Making your software: Step 3 - Ball Park Estimates

Priya, our fictional software entrepreneur from the previous chapters on this series has a dream to make “Designly” a software platform for interior designs. She has followed our suggestions on writing down her features in the specific format that software developers love as step 1 in her journey to make her software. She has then gone through the methodical approach of finding possible software developers using a simple yet effective process using the method laid out in step 2 - find software developer She now has a shortlisted software developers who are likely to be a good fit in terms of skills, capability and communication. Now is the big question of money,

“How much will it cost?”

But costing a software development project is not as simple as just saying oh these are the materials, this is how much it will be. That is because there are a multitude of unknowns in a software project. If you take Priya’s situation you’ll know what I mean. She only has an idea of software and some features. Roughly she is looking for a software that will:

a) Let users try out interior design in their room.

b) Take pictures of those designs and ask for feedback from friends and family.

But is that all? If you dig even a little bit further a hundred new features starts coming up that are essential. For example:

c) users will need registration, password management, trial access, etc.

d) there will be a need for a payments

e) priya will need administration interface for managing her users and also for stats.

f) ….

And we haven’t really even scratched the surface yet. For example, how does a user do the first feature of trying out interior design? Will there be little furniture pictures that users will be able to arrange? Will the user have ability to change colors of the walls and furniture? Will there be a library of furniture pictures? …

Each of these questions and their answers lead to features and work which leads to change in the cost. The actual requirement analysis is by itself a big part of the software development work and it takes time and effort to do. So for any sane software company it just doesn’t make sense to go through the whole process without getting paid or without some assurance of getting the full project. But on the other side Priya needs to have at least a rough idea about the costing of the project - will it be a few thousand or a few hundred thousand? And the answer to this predicament is

The ballpark estimate

An estimate that can be wrong in the actual number when all the requirement is done and dusted but which is at least in the same order of magnitude. So it’s like a software developer saying “hey, Priya, your software will cost something around 50K” and the actual final cost might be 80K, but it wouldn’t be 500K for example.

For any software company with experience and skill, coming up with a ball park is relatively easy. It will probably require some effort - maybe a day or two (and even a week) of going over what’s known and trying to guess the effort. But it’s far better than spending weeks on scoping and estimation work without knowing for sure if the project will be awarded to them or not.

So most software companies are OK in the little investment of coming up with a ball park number.

The art of estimating the ballpark number

Ballpark numbers are very rough cost estimates based on the specification you give to the developers. This number helps you figure out costs and plan your funds. To get a reliable ballpark you’ll need to spend some time with the developer to go through your concept, answer their questions etc. And obviously you can only do that with only a few.

Most software companies will guide you through the ballpark estimation process by asking questions. But from your side you need to take some action too to make sure that the right questions are asked and that certain concepts are clear to the software developers. Here’s our list questions that we make sure we ask and clarify:

• What is the closest thing like your software currently available? Can you give us a link?

• Do you have any preference on colors and themes? Can you give us an example site/app?

• Where do you expect your users to use the software the most - on their browsers or their mobile devices?

• Do you want a mobile app too? If so do you want them on both iOS and Android? Why?

• Tell us in your own words how your users will use the software.

• Tell us in your own words how you expect to manage the software, users, accounting, etc.

• Tell us about your potential users. Would your users be computer savvy? Would they have good internet connections? Would they have good devices?

• What would be the language preference of your users? Do you expect your software to be multi-lingual?

• What’s your “drop dead” deadline? When do you need your software by to survive as a business?

• If you were to choose just one feature, what would be that feature?

• Going forward what is your expected cost of maintaining the software?

• Who is going to maintain the software? What sort of skills does she have?

Making your software: Step 2 - Find software developers

Priya, our fictional software entrepreneur from the previous chapter on this series has a dream to make “Designly” a software platform for interior designs. She has followed our suggestions on writing down her features in the specific format that software developers love as step 1 in her journey to make her software. Now her big challenge is to find a software developer company who will turn her dream into reality.

This is not an easy task. There are literally tens of thousands of software companies in the world. How would Priya find the software company that’s a right fit for her? Let’s try breaking the problem down a bit and see if we can come up with a strategy for finding the right software vendor for her. Let’s define what we mean “fit”:

For Priya, as an early stage founder, fit means the 3 following things in the order of their importance:

1. The communications is good between Priya and the team that will work on her product.

2. The cost of making the software is within budget.

3. The software vendor understands the nature of early stage startup projects like Priya’s.

Let’s go over these points and see how Priya can find software developers with these points in mind and also check for the fit.

The Fit

Communications is the key

Priya is not a software professional so she needs to find someone who can communicate various technical jargon and issues easily to her. Even if she was a techie herself, as an early stage founder she might not have the time to focus fully on her project - since many early stage products are “side projects” where the founders have a day job to worry about. So Priya needs to find a software developer who speaks at the same wavelength as she does. A developer who understands well what she wants to build, her business priorities, the “low hanging fruits” she wants to pick and can tell her in simple terms what technical challenges there are, which decisions win her time, which compromises saves her money without losing a lot on features, etc.

Let me stress this once more: communications is the MOST important thing for a software project. If everything is perfect, if Priya finds the world’s best software team working at the just the right cost for her and she then finds that she can’t communicate with them well then she needs to look elsewhere. Simple rule, yet many early stage founders falter here. Maybe the cost savings or the flashy tech skills make them think it OK if there are some issues in communications. Sometimes they think “software engineers are like that, they will always speak in jargon and I have to accept that and try my best”. It’s simply not true. Software can be complex and obviously very technical, but a good software team will always ensure that there is someone in the team who understands software jargon, “nerdy” engineers and also business priorities and the founder’s thinking.

Staying in the ballpark matters

Cost is a big concern Priya, obviously. She has limited budget and she has fit all the costs for software development, hosting, advertising, travel, etc. in that. The actual specific number is something she will calculate as part of the planning that we will cover as step 4 in her journey. The reason for delaying this, instead of taking it up as an initial thing, is for her to get an idea about potential software development cost. Software development cost varies wildly depending on what she wants to make and also on the vendor she wants to use to make it. But whatever the situation she has an idea about the maximum she can spare for her project, e.g. she will know that she can’t spend a 100K for sure but she will probably be able to scrape out 10K. With such a number in mind she can then narrow down her search for vendors, taking out obvious ones out.

Experience with startups is important

Most early stage founder driven software projects are a wild journey. Pretty much all such projects start with a certain plan but end up being completely different. This is the nature of the game. The need and flexibility to pivot is extremely important for the success of Priya’s software. This is because both Priya and the software vendor doesn’t really know for certain what will be acceptable to the users of the software. Priya does a good job with her experience in dealing with her customers to find out the pain points and use the template in step 1 to create user goals and stories. But those are just her assumptions. They are tainted by her bias about what she believes her software can do. They are not test on the field by real customers. And she may find out really early on (hopefully) that certain features need to be changed a lot to meet what her customers really want.

The software vendors are typically in a blind spot too about Priya’s customers. They may know a thing or two about what features are good and what are confusing. They will definitely know (if they have the experience) that they should limit initial features to bare minimum focusing on the biggest pain points for her customers. But at the end everyone is shooting things in the dark. This is why the software vendor needs to have the understanding and experience about startup project like Priya’s. They should know that the project features, needs and timeline will vary as the project progresses. They need to plan for this possible change and accept it as the norm. Their experience will also help guide Priya towards taking the right decisions.

The selection process

Now that Priya knows about the fit, here is a process she can use to find and filter the software vendors. This process has worked for hundreds of our startup founders so we can vouch for this.

1. Compile a list of software companies and score their online presence and reference

Google will get you the names of thousands of possible software companies. But before Priya does that she should first reach out to her friends and family for any vendor they know or have an idea about. The best way to find a good software partner is through reference, it saves Priya a huge amount of time and energy. If the reference is really good and from someone she trusts, she should still do the scoring for fit as given below, but she can save time by not going through the compiling a list of candidates and comparing them. The referred company checks fine on fit, she can just go with them.

If Priya is relying on Google to find names, “custom” or “bespoke” is the right word to use to filter out software product companies (that make their own software only - like Microsoft) from the software consultancies that makes software companies for others like her. Here is a good search phrases she can try:

“Custom software companies in ________ “ (if she is looking for a specific location like her town or a specific country because she heard the costs are lower there).

Apart from google, there are directories where Priya can search for software companies - these usually come with reviews (take them with a pinch of salt though!), example projects etc. Here are some directories that are pretty comprehensive:

Clutch

Goodfirms

G2

When collecting the names of the companies it’s easy to get carried away and end up with dozens of names. It’s a big time waster to go through a large list, so it’s always a good idea to do a filtering even when compiling the list of companies to consider. Priya should look at the companies website and their work portfolio to see if they look good and have worked with early stage founders like her. Some custom software companies only work with big enterprises and their DNA will never match with what Priya’s project needs. Another important thing to check is how active the company is currently. Many software companies start out doing a few interesting projects and then lose their energy and become almost a relic that tries to leverage on past glories. Priya should look at company’s social media posts, recent posts and tweets to get a feel about how engaged and energized the company is. Another important check is looking at some LinkedIn profiles of key members of the company to get a feel about their experience and their involvement with the company.

Based on the companies online presence give them a score and if a company comes with reference you trust give them a score on reference. Our vendor selection spreadsheet template that you can download below has a cell for these scores against each vendor.

2. Email software companies and score the experience

This initial email itself is good way to test the candidates for fit and filter out some companies - that is where the scoring comes in. Here’s how: the email Priya sends out would be intentionally vague. She would of course mention she wants a software made, but not give a lot of details or give conflicting information. The reason is it to test the communications right from the start. Any reputable software company will prioritize incoming business leads like Priya’s email. So it would go through a certain workflow. In some companies it may go from customer support to a business team, in others it may jump directly to a decision maker. The flow, the time to respond, the process of clarification about her vagueness, the quality of the reply, the position of the person replying and the message itself will give Priya lots of hints about the quality of communications in that company. If, for example, Priya gets into a loop of emails, where she gets thrown from one person to another in the thread it’s a BIG red sign. It would probably indicates bad work process or communications channel at the company and something very similar would happen during the project. So, this initial email and the response is a great test (easy and low cost!) that Priya should score.

3. Run a survey and score the response

Now that Priya has list of software companies she should send out a standard survey to all of them and ask them to respond. The survey should address some of the basic issues she needs to know about a company so that she can compare them side by side, but also the survey should be done in a way so that Priya can use the answers to create a score for each company. When there are a bunch of similar companies, that all seem to offer the same services it’s always hard to compare, so it helps turn things into scores that can then be compared objectively. However the responses of the survey should also give Priya some idea about the company’s way of doing things, their culture etc.

We’ve given a template for such a survey as a spreadsheet (part of the download with this post). This will give an idea about what are good questions to ask in a survey like this, however each product and situation is different so the actual survey will probably need some tweaking. Separately it also makes sense to run the survey with a survey tool like google survey or surveymonkey

4. Call the top 5 companies and do a call. Score the experience

Now that Priya has 4 scores for each company from #1-#3 above she can get the top performing companies in that list of hers. Note that the scores are not all the same, they need to be weighted on the aggregate score. This is because a reference from a friend you trust is obviously a more reliable score than a random email thread that went wrong (maybe the person answering that email was a new employee who didn’t know the process…). We suggest a weighing in our template (downloadable below).

Priya can use the scores (and also her instincts - she may have liked a company much better than their score) to select a few (5-7 is a good number, too many is a time waster, too few is a bit risky) top performers and ask for a detailed call to discuss her current requirements. The verbal conversation is important as it will double check on communications. It will also let Priya test how pro-active they are. Note that this is not the call to discuss the product in detail or give them the rough spec (from step 1) to give estimate. That will be step 3. The reason Priya should delay that discussion is that she should get a non-disclosure agreement (NDA) done and also she doesn’t want to go through the time consuming requirements discussion with so many companies. Her goal is still to filter out maybe 2-3 companies with whom she will get to step 3 level details.

5. Calculate a final weighted score

Now that Priya has 5 scores: Online presence, reference, email, survey and call, she can do a total score. But not all the scores are the same value - so a simple average won’t be a good idea. We suggest making weighing reference and the call the most. Here’s our suggested formula for the weighted average score (it comes with the downloadable template spreadsheet at the bottom of this post):

Weighted average score = [online score + (3 X reference score) + (2 X email score) + 3 X survey score + 4 X call score ]/13

Moving forward…

Now, at last, you have a spreadsheet with a list of software companies that are scored on their merit and you can do a simple sorting on the total score to select the top ones that you will actually spend time with to explain your idea and get them to give you an estimate - a “ballpark” price. Reason it’s still ballpark is that most companies would only give you a final “fixed” priced project if they do a more detailed specification with pictures etc. That takes time, and you only want to proceed to that after you know if the pricing will fit with your budget. A ballpark estimate helps you in this regard. If the ballpark is something that you can fit into your budget then you get into the next step, if a company that scored high yet gave a ballpark estimate way beyond your budget (happens a lot, software price varies wildly because of all sorts of reasons) you’ll need to get them out of your list. OK, onto the ballpark estimate then…

But that’s step 3. So we are done for today!

If you liked this, try out the founder’s power pack that we are putting together to help all founders in their journey through the software development process. Click on the image below to know the details.

Making your software: Step 1 - A rough specification

Meet Priya

Priya is a successful interior designer. So successful that she just can’t find time to serve all the projects that come her way. She has a brilliant idea about a software solution that will be able to scale up her operation. A mobile app where many of her customers can actually do their own interior design planning work and then reach out to professionals like her to put the finishing touches to the plan. She knows it will be a great hit, but she has never worked on software project and has no idea where to start.

This series of posts is to help people like Priya. To help her walk the many steps that lead to a successful software launch. This is the story of her journey, with today’s post as the first step she needs to take - create a “rough specification” - a list of features for her software. This list of features will help her explain what she wants her software to do. She will need this for software developers who will build her app and for investors who might fund her.

A name for her product

It’s best to start with a name.

A name of the software project makes life easier, Priya will not constantly need to say “oh that software for helping people do interiors” - she can just use the name. The name doesn’t have to be final, she can stick to a temporary name and use a name that’s different later on. But it’s important to think of a name that gives a feeling of what the software will do. This thinking of a name helps to kick start the thinking for the software’s feature list work too. And, if she can think of a great name that she will use in the real product she can actually buy the domain too. Giving a name and buying a domain actually helps make the project feel more real to her.

After some soul searching Priya decides to name her software “Designly” but decides to buy the domain later as the exact domains were not available (this would be true for most names you can think of - selecting the domain name will take some imagination!)

The user goals

The next thing Priya has to do is list out the goals of the Designly: what will her users achieve when they use Designly. This list is usually called the “user goals”. By listing the user goals out first and keeping them in mind when she thinks about features she is ensuring that she makes Designly useful for her users. Here are some example user goals for Designly:

1. Users will be able to design their interiors without getting expensive professional help.

2. Users will be able to quickly try out variations of their designs and colors.

3. Users will be able to find great interior designers close to them if they need experts.

It may take a few days of thinking to come up with the user goals list. It’s best to give it the time, to think all the goals through, as some goals are not quite obvious, yet after writing out some of the goals they may come out as obvious goals. Here’s one that may make it in Priya’s list which might not be too obvious at the beginning:

4. Users will be able show their designs to friends and family and ask for opinions.

After all, a great value for a software like the one she is planning is that people can try out designs and check how others feel about the design - just as we do in real life for other things.

The user stories

Now that she has the goals listed out she has to come up with a list of how the user achieves those goals. This is usually called user stories in the software world. If she lists them out in a nice easy spreadsheet her software developers would love that. This is what their product analysts have to do anyway and she is just fast forwarding the whole process with her list and also saving a bunch of money.

Here’s a way most software developers like to write these user stories. It all comes from the Agile principles of software development, and it’s worth reading up about this a bit. This agile way of making software is the best for a startup project like Priya’s. So here’s how Priya needs to write the user stories, she should structure each of the stores in the formation of:

"As a ………………. I ………………. , so that ………………. ."

Here’s an example from her product:

"As a home owner, I want to easily try out different colors in my room’s design so that I can see what combination works best for my room."

Since there’s likely to be a whole bunch of these user stories with some of them more important than others it’s good to have them in spreadsheet with the columns laying out the structure and with additional columns that can give other information. We always tell our founders to keep it simple, it’s important to get the thoughts in place rather than worry what’s the right and the wrong way of doing things - since there is no right or wrong. Here’s an example of such a spreadsheet:

A picture or two

With the list of goals and stories Priya would be miles ahead with her software project. She would have something to talk about with software developers or investors. But one extra little effort would magnify her effort by a lot - creating some pictures. You know how it goes - “a picture says a thousand words” (btw, if you ever wondered, that line is originally from Ibsen - morphed into what it is now). In the software world pictures are needed not only because of the thousand words, but also because they might tell the right set of words. Here’s a great picture that explains this (again proving that pictures can explain things so much better! We’ve used this before in a related article that’s worth a read for Priya too: interface between technology and business).

Priya doesn’t have to do anything fancy to make the pictures. Even some hand drawn pictures of how she thinks the software might look like or interact will be a great addition to the rough specification that she is making. But we suggest a great tool that is used by professionals and non-software people around the world: Balsamiq It’s a really easy to use software that let’s you do quick pictures of software interfaces.

With a tool like balsamiq Priya can churn out some concept pictures about the software very quickly. They don’t have to follow any “software UX best practices” or anything, that’s the job of the UI/UX experts. But having these pictures does a double check on the list in the spreadsheet and also helps Priya think through how the goals and stories might actually be in a real piece of software. This understanding of the process of translating words into software interfaces, the difficulties involved and the thought process is invaluable during the actual process of making the software. It would help Priya understand the timelines, estimates and also make her very effective in giving feedback to the designers when they do the actual software interfaces. Here’s an example of how one Priya’s drawing might look like. Even this single picture would help the software developers so much to understand what Priya is thinking of in her software.

That’s it for this step. With the list of goals and stories and with few pictures of the software interfaces Priya is all done for her specification. Now she can find any software developer (the next step in her story) and explain what she needs quickly and ask them to give a price idea. I can tell you that any software developer she goes to will have a happy face when they see her rough specification ready for them!

If you want to use our template for the goals and stories, download it by clicking the button below…. Watch this space for the next one on the series that helps Priya find software developers for Designly.

If you liked this, try out the founder’s power pack that we are putting together to help all founders in their journey through the software development process. Click on the image below to know the details.