Top Benefits of Hiring an Offshore Software Development Company

There’s a constant uptick in security breaches of companies around the world. It’s a never-ending concern for security professionals, especially since countless organizations are not giving it much attention.

A study by IBM Security/Ponemon Institute conducted in 2019 concluded that the average cost of a data breach is $3.92 million. This raises an important question, "What can companies do to safeguard themselves from these attacks and potential losses?"

How do software vulnerabilities affect businesses?

Software vulnerabilities are flaws or weaknesses in software that compromise the security of a company’s system. These issues can be critical for businesses as a data breach or system attack can easily cost millions of dollars in compromised files, operational challenges, and system maintenance.

How to prevent security vulnerabilities

Data breaches show no signs of letting up; therefore, having secure software is vital to every organization. Although not all attacks can be fully anticipated, many can still be avoided by following the tips below.

Define Security Requirements

You must ensure that security requirements are clearly identified and observed during the entire software development life cycle. This includes business objectives, company policies, risk management programs, and applicable laws and regulations.

Be Mindful of Third-Party Software

Minimize the risks of being exposed to vulnerabilities by managing the use of unsafe third-party components. If using third-party software is inevitable, only use those with Code Signing Certificates to guarantee its authenticity, effectiveness, and trustworthiness.

Consistently Identify Vulnerabilities

Limit an attacker’s window of opportunity by regularly checking your systems for vulnerabilities. Assess and test the software's code to identify new risks. Establish an efficient response program to ensure security researchers can log weaknesses as soon as possible. 

Get Help from the Experts

Since developing innovative, functional, and secure software is what software development companies focus on, they have a strict and consistent process and guideline that they follow for every execution. In a nutshell, they’re the experts who can effectively help your company with your infrastructure.

Why hire an offshore software development company?

To help businesses decide how software development vendors can help with their system security, we’ve broken down the top benefits of hiring an offshore software development company.

Guaranteed Security

Trusted software development vendors are experts in their industry, especially with system security. They are knowledgeable about the dangers that companies can face and how to mitigate them. Partnering with the right firm means you’ll have access to professionals that would turn your business and security requirements into a reliable product.

Cost-Saving

Outsourcing your development project is a more efficient and financially sound choice since you won’t have to hire and train an entire team to create software. You can use the money you save for the betterment of your company.

Reduced Liabilities

A software development process requires a lot of valuable time and resources. It demands full attention on the core objective, from the inception phase to the deployment of the solution. 

To maintain the project, you must have a dedicated team to handle the task and acquire the tools for development. These obligations can be expensive for companies, especially for small and medium-sized businesses trying to minimize liabilities while maximizing the efficiency of available resources.

Faster Development Time

Competition is tight in today’s market, so producing secure and functional software in a short time will benefit a company. In-house development requires hiring software developers and researching rigorously on the best tools needed. Without the technical know-how, this can take a lot of time and delay the entire process and compromise quality.

Utilize The Top Resources And Technologies

The technology landscape is rapidly evolving, with technologies such as artificial intelligence, blockchain, natural language processing, and many more changing how industries operate. Different resources are being utilized in offshore development, which enhances the development life cycle and their ability to create powerful software that influences innovative technologies.

Offshore development offers a simpler course to expanding your business and leveraging the decade’s technological advancements. Not to mention the security and peace of mind that it can offer your company. Ensure seamless business continuity and growth with these insights.

Introducing new features in your released software

Imagine this: you have released your software. As with any software releases, you had cut corners, last minute compromises had to be made, features had to go out without all the bell and whistles, etc. Yet, you users loved the software, and they have started to use it. As you start getting new users, you are also starting to get requests for features you had compromised on during the release. And people are complaining a bit about the UX, there were things you had thought made sense but it’s not so obvious for your users. You now realize that you have to update your software with a new version.

The good news is that it’s a web app, so updating is just releasing a new version overnight, making sure people’s data isn’t lost and you are done. But the bad news is that your UX fixes and new features mean you’ll need to revamp how the software will be used and the interface is likely to be completely redone. It’s bad news because you know that some people will get confused with your new UI because they’ve learnt your current interface and are using it.

What do you do?

Here are some strategies that we’ve been advising our clients with and they come from working on hundreds of app releases and update.

Release often, but only at the start

“Be agile; release early; release often.” that’s the the drill. But it is strategically wise to keep rolling out features only at the beginning of a product roll out when you don’t have that many users. When your product reaches a certain size, a certain number of users, you don’t want to risk the integrity of your application with every new minor release. The worst thing that can happen to your product is that loyal users, customers who have been using that one little feature consistently over the years, suddenly aren’t able to use it in the same convenient way. The change might empower users more, but the experience becomes less straightforward. Frustration and anxiety enter social media quickly and suddenly, and the pressure on customer support to respond meaningfully and in time increases with every minute. Of course, we don’t want to roll out new features only to realize that they actually hurt loyal users.

So the plan should be:

Release early, release often only at the beginning of product’s life

Announce the release

You should have a list of its current users. Use that list to communicate that changes are coming so people are prepared. Plan on sending an email announcement, explaining your new upcoming plans, with dates and list of feature changes.

Create a video showing what’s going to be new and more importantly how it will improve things for your users. Remember, this not just a boring news of updated software but it’s an advertising to get your users excited about the new features. That excitement will help ease the pain of learning and adapting to the new interface or the new way of doing things. A lot of people are visual learners and this preview will make the changes feel less unknown the next time they use your software. Sometimes even a animated gif does the job well. Here’s google introducing a new feature with a very short animated gif.

Or basecamp doing a in app popup letting people know about changes that are about to happen. Trello does something similar with their “New stuff!!” fox at the top.

Have app Tours & Walkthroughs for new features

When your users use your app all day long a new update can greatly affect your efficiency. You can easily address that negative by providing a short and easy in app tour to re-teach user behavior and help users with missing or moved features. There are different types of tours, but the ones that point out and walk users through how to use a new feature and answer any common questions works the best in our experience. Gmail has a great one that you must’ve seen. Here’s one I saw recently that I liked.

The good news is that it’s easy to add these in app tours. There are several great products out there that makes it pretty easy. Try out Stonly or Intercom for a start.

Have a “I’ll try later” option

This may not be the easiest option from a dev point of view, but it would be wonderful if you can do it somehow - the option that let’s users use the old interface for a while. Very useful when your users have something urgent to work on and you come in with your all new shiny interface where nothing is where it was! Facebook has them all the time when they do their big UI shifts, but they are Facebook. But you don’t always need thousands of developers in your team to do this. Nifty tricks like having the older version still available on a server and click to redirect users to that version might suffice in some cases :)

Ask for feedback

Sometimes all it needs for your users to be OK with your changes is a simple “sorry for the changes, we welcome your feedback” message somewhere. This humanizes the software and let’s your users know that you are putting them in trouble and that you are willing to listen to them.

Remember how angry we would get every time MS would drastically change their interfaces? We learnt the new way of doing things but we were looking for some way to tell MS what then shouldn’t have done!

Anyway, software is always going to be updated, so you’ll just need a way to make those updates less obtrusive to your users. This is a fact of life! Happy software development…

A software UX design story

This is a story taken from real life. One our customers from the Netherlands approached us with a very interesting idea of a software for gamifying trainings they run. They run trainings for big corporations - stuff like corporate policy, safe working habits, HR good practices, etc. The problem was that the topics were just not interesting enough to keep the attendees engaged. They needed something that would bring in more interest and engagement from the people attending the trainings. And their solution was to gamify the training sessions. They had rough outline of what would work in their heads but nothing in form of documentations. The big challenge thrown to us was capture all the ideas they had, pin them down to software features and also think of ways to make the software usable. This led to a requirements capture and UX design story I’m about to relate…

Chapter 1: Finding the need

We held multiple sessions with the clients and their presenters to gather information about their current working procedures and business needs and singled out the three major requirements:

Chapter 2: Brainstorming

After multiple session of individual and group brainstorming on possibilities, we landed on the idea of developing a gamified presentation eco-system that would include 3 to 5 minutes of lectures or video presentations followed by pop quizzes about the current segment. The participants can engage with quiz live from their mobile device, competing with their peers, gaining points with the goal of being among the top scorer on a live leaderboard.

We came up with four major components

Some key concepts for the components were

Editor:
Create, configure and manage Shows
A show editor
Schedule, share and manage sessions

Projector:
Host's screen:  
* Initiate and navigating a session
Projector screen:
* Showing slides including presentation part and quiz part
* Live responses from users on quiz sessions
* A Live leader board.

Controller: 
A responsive and contextual version of the projected show
Interaction with the quiz slides
Questions, comments and feedback on a slide 

Auditor
View results of a session
Generate reports

Chapter 3: Personas, Use cases and Storyboarding

The next step in our design process was to identify the personas - the typical users of the system. This exercise was done mostly within the design team with a summary session with the customer to get their feedback - we had enough notes from our original brainstorming to identify the typical users of the system.

We then moved on to defining the various uses cases for each personas where we drew up how a persona would use the system to get their job done. For example: How Tom, Dick and Harry, with different personalities will access the show in their own ways.

Instead of just writing them down in spreadsheet or document, which is the standard practice, we decided to do a more graphical representation as this would aid in faster communication of the ideas.

Chapter 4: Prototyping prototyping prototyping

Now that we had a solid idea about how the system would work, we moved on to building prototypes.

We started with horizontal prototyping capturing the global bird’s eye view of the whole system then vertical prototyping drilling down to specific features. Constantly evaluating and refining and gradually moving up from low-fidelity wireframes to a high-fidelity deliverable. 

Chapter 5: Evaluation and hand over to development

The prototypes helped us evaluate the product concept without a single line of code being written. We iterated over multiple version of the prototype by incorporating feedback from the customers and possible users of the system.

With the final version of the mockups done with a graphical prototype acting as a very clear spec document, the dev team moved in to develop the product but that's not the end of the design cycle. With feedback from real users and various stakeholder of the system, we had to to go through a few re-iteration of the design till all in the comfort zone that it was done right (enough).

Great story isn’t it?

Adapted from the original at: https://www.dpixelman.com/ by one the best man to lead our design team, Zahid, who has now moved on to newer things.

MVP to Startup Success

MVP stands for minimum viable product and making an MVP is the only real way a startup can succeed. Making it saves both time and money and let’s a startup find it’s path to a product that the market needs.

What is an MVP really?

An MVP is simply put a cut down basic version of a product that is designed to test the market and get feedback. As a concept it’s been around for a long time, with people trying on “0.1” or betas, but it was popularized as startup process, a survival strategy by Eric Ries and his superb book Lean Startup. Let me let the guy explain it to you himself in this video.

The MVP is based on the concept that early adopters can test and provide feedback to improve the product. Not only the feedback but also test the business viability of a product can also be tested before a founder invests too much on a product.

Here are some things to think about when you as the founder are thinking of making an MVP.

Build the Core Idea

An MVP focuses on one idea and one idea alone. It does not include any other features. The goal should be building a product with a minimal budget in the shortest possible time. So the focus needs to be on the main features that solve a single pain point of the target users. Nothing more. So leave out those export functions and those customizable reports that all products seem to have but very few people seem to use.

Test Early

Even within the small scope of the MVP, the testing early concept is very much needed. Have a plan to start testing from the first day of development. Don’t think that just because you are building a small scoped MVP you can wait until the developers say “it’s done” - that defeats the purpose of the MVP which is a purely experimentation and try things out way of doing things. You as the founder and your team should have the mindset that you are just testing the water as you are building out the MVP.

Have a User Group

The MVP offers the possibility to find out your potential users’ opinion, and how they want to see your final product. So although your own feelings matter and should be the first round of test on the MVP the main goal is to let real users try the product. It’s difficult to find that user group, so start working on creating a group of ideal users. You’ll need them soon enough!

Validate the Demand

An MVP helps you understand whether your app is right for your target market. It should present your brand well to the users, and show them how your project is unique as compared to others in its category. Test out the market viability. Ask users how much they are willing to pay for it, how much time they would spend on the app, would they refer it to their friends and family, etc.

Test the Marketing

Run small digital marketing campaigns, see what the click through rate. This will test how much traction you’ll get with the product. This is the time to test variations of the marketing message. Find out what message gets the best results. This will not only tell you what works for marketing but may also tell you what your users are really looking to buy.

Here’s an example of an ad campaign run for a project management tool, targeted at exactly same demographics both on social media and direct feedback. The one one left got much less traction than the one on the right. The difference is very unlikely to be the imagery or attention as the same graphics same fonts etc. was used. What can this tell the founder? One possibility is that people aren’t looking for project management they probably want team planning (although both were in the feature list). Maybe a little more testing will help, but if this proves to be true the MVP should focus more on the team planning aspects?

Test the Burn

MVP is also test for budgeting and the burn rate. Use the MVP to test how much it costs to do a feature, how much it costs when you pivot on features. A very close monitoring of costs both financial and time is absolutely necessary to give you a good data with which you can predict future costs.

Test the Team

Last but certainly not the least, the MVP is a great way to test the team and it’s collaboration. Whatever happens during the MVP will happen (and happen at a greater scale) during the real product development. So test the teams abilities, collaboration skills and communications. Find out what works and what doesn’t. Use this finding to plan fixes, figure out what you can do to improve the known issues. Try testing the improvements too if possible during the MVP.

That’s it for now! Have a great weekend!

The no 1 skill for software founders

As a software founder you have to be a master of everything. You have to wake up with the motivation of Tony Robbins, morning routine of Elon Musk, run meetings like Bill Gates and finance like Jeff Bezos. It’s not easy. Yet, as a software founder, none of these skills and abilities are the number one skill that you absolutely have to have to be successful. That number one skill is

The ability to scope well

Or in other words, the ability to decide what features to do and what to leave out. This single ability alone can get you a software that you can afford to build and that people want and will pay for.

The good news is that this skill is something that can be learnt. Here are some guiding principles that can help:

The Pareto Principle

Way back in late 1800s an econnomist named Vilfredo Pareto came up with a simple idea:y 80% of the effects come from 20% of the causes. This is now known as the Pareto principle that gets quoted in every where people are trying to choose what to do and what to leave out.

It sounds too generic, too optimistic. Yet the funny thing is you’ll find over time it’s spot on. OK maybe not exactly 80% to the dot, but close enough. In the software context you could rephrase it as: 80% use of a software comes from just 20% of its features. So - if you could get to those 20% only you’d make most users happy. Think of the huge benefit, 20% of the costs (and time and effort) to get you enough of a software to go to market.

Another place in software where this 80-20 comes in is fixing bugs. Software will have bugs, but if you can find the right set of 20% bugs you can probably cover 80% of the issues. There’s a famous story (probably true) of Microsoft’s ex CEO Steve Balmer sending out an email about how this has clearly been proven by stats on bugs on Windows XP.

So be aware of the famous Mr. Pareto and learn to hone your skills for finding those magic 20% of what needs to be done.

The MoSCoW method

The MoSCoW analysis is a simple process for identifying priority items. It’s used to classify requirements into different groups according to their significance to the customer.

The process of MoSCoW analysis in software requirement analysis involves taking each possible requirement in your software and putting it into one of the following sets:

• Must have : Something that must be done. Without it, it doesn’t make sense to release the product.

• Should have: Something that should be done. You can live without this feature, but you risk losing a significant amount of customer interest if it’s missing.

• Could have: Something that could be done. It’s a “nice to have” that makes the product better for your users, but at the same time it isn’t all that critical for your success.

• Won’t have: Something that would be nice to have. If you’re done early, this is a nice, but really it’s neither required nor important to the majority of your customers.

Looking at these groups, you might think that such a grouping is something product management (or the product owner) could do on their own. But it’s really your job. Only you can see the full picture of time, effort, budget and time to market. The market (and your competitors) aren’t going to wait too long for your Must haves to be done. They’re going to move on. That’s why it’s important to do the MoSCoW analysis jointly between product management and engineering. If you can identify a Must have which isn’t feasible in a reasonable time-frame, you need to find alternatives, the sooner the better.

$100 test technique

This technique is described in the superb Managing software requirements (Leffingwell and Widrig) book. The idea is pretty simple:

1. Get all the major stakeholders in a prioritization session and then make a list of features/items that need to be prioritized.

2. Give everyone imaginary $100

3. Ask them to divide the amount among the given options (user stories, tasks, requirements).

4. Add up the dollars for each item once everyone is done and then you get to know which items are most valuable (and should be done first)

Five whys technique

The five whys method is part of the Toyota Production System. Developed by Sakichi Toyoda, the Japanese inventor. It’s the simplest thing on Earth, yet amazingly powerful in revealing hidden details of any problem. The process run by the analyst (usually you) asking the stakeholder (usually you again, so you asking yourself) repeatedly five times why the requirement is necessary until the importance of the requirements is clear. The answers reveal whether the requirement is really important or if can be delayed.

That’s it for today, if you really liked this and want to dig deeper, this is a hot bed of methods and techniques and recipes. Google and you’ll find a treasure trove. And if you want a superb book to read then the classics would be Agile Estimating and Planning by Mike Cohn and the aptly named Software by Numbers: Low-Risk, High-Return Development by Deene and Cleland-Huang

Software by Numbers: Low-Risk, High-Return Development

By Denne, Mark

Agile Estimating and Planning

By Cohn, Mike

Software beyond the pandemic: The Rise of the Online Explorers

This infernal COVID 19 pandemic isn’t going away so easy - we just have accept this fact and move forward. Moving forward means - adapting. We are all adapting. Most companies in the world has adapted to the concept of work from home. It felt like a very difficult task, specially for the industries that were not IT driven, but as with any new concept - once the wrinkles has been ironed out it’s working out fine. In every industry, in every country in the world people are coming up with innovative solutions of adapting their work and life around the facts of social distancing and lock down. Software world is probably the most prepared for that adaptation, we after all are the facilitators for most of the adaptation with technologies like online conferencing, project management, file sharing, come to think of it, online (and offline) everything! But beyond the facilitation and the continuation of the old paradigms we also have to start thinking of how the world will change, how the new world beyond the pandemic (yes there will end to this someday, there has always been one, even black death) will change it’s behavior for consumption, software usage and living it’s life.

We don’t know. We can only predict. But what we know for sure is that there will be many permanent change to how we lead our lives. And as the leaders of change, us software people have to come up with new ways of doing things.

Online concerts and events

Here’s one change that has already started: online experiences for what used to be face to face events. With the lock down in place events like stand up comedy, football games or concerts can’t take place anymore. The alternative is to have them online of course. And we see that happening in many platforms. A great starter event for this new way of doing things came when the greats like Lady Gaga, Stevie Wonder, Shahrukh Khan, and many others came together to support the WHO with an online streamed show recently that raised almost $128 million for the COVID-19 Solidarity Response Fund, as well as local charities that are fighting the coronavirus.  

This overall movement towards online events is a natural progression from where we where before the pandemic. The virus only pushed us more and accelerated us in this direction. What is more interesting is:

“Will this become the new normal beyond the pandemic?”

I would argue yes. The pandemic will change our mindset about online entertainment, it is giving us a taste of the ease of online live streamed events and we like what we taste. On top of this our habit in consuming such events over prolonged time of the social distancing along with residual fear that will likely to remain for a while after the dust has settled will cement the success of these online experiences.

In line with that thinking online venues (the alternate of concert houses and stadiums) are coming up everywhere. Facebook pages like the billboard are picking up huge views. Pickathon launched the series "A Concert A Day" on April 8, which raises money for the MusiCares COVID-19 Relief Fund. Every day through June 7, at 1 pm PST and 4 pm EST, a new performance will be premiered or livestreamed via the Recording Academy's Facebook page, Amazon Music's Twitch channel, and Pickathon's YouTube channel. Featured artists include Margo Price, Mac DeMarco, Tyler Childers, and Foxygen. This is just the beginning.

Beyond online concerts

The interesting trend is that the online experience is going far beyond the old concerts and event streaming that we were used to in the good old days of pre-pandemic world (aka ancient times of 2019). Airbnb for example has focused on hosting “online experiences” as an alternative to their hosting your house for strangers mode. In their words:

These online experiences are as varied as their hosts are imaginative. You can cook with a family from Morocco or go out with someone and check out how the dogs are doing in the post nuclear accident Chernobyl.

This is the face of the new online exploration. This is just the beginning. There is so much more that can happen in this space that is unexplored. Take trips to interesting places for example. The obvious space for that is arm chair based world travelers who asks local experts to visit places they want to see, look at things they want to look. This already existed with 3D videos (and VR apps) like visiting Angkor Wat virtually or Vineyards but the post pandemic world will likely see an explosion of interest for such online explorations.

VR and AR technologies will need to catch up with human expectation for such online experiences. So that is the new horizon for hardware improvements for sure. Again it was going that way anyway, but the pandemic just pushed it harder and the demand for this will be much more stronger than the lukewarm early adopter space it was hovering around in.

Looking forward to that brave new world of online explorations. Life will be interesting. One little pesky virus will not put the spirit of human exploration down for sure. We are working on it but stay safe for now though :)

Why software startups fail?

Did you know that most software startups fail?

Yet majority of the startups that fail actually have great business ideas. Take the failed startup Kettlebell Kitchen for example (shut down Nov 2019 after 11 years of trying). If you think about their idea it sounds fantastic - people want to eat well or use a particular diet -> It’s hard to maintain it yourself -> use the software to receive meal kits based on nutritionist’s advice and stay on the program. Takes on the restaurant/food business as well as the health and fitness industry in one single idea.

Yet with more than 30 Million in funding, 11 years of coding (and I’m guessing struggle) we have a company that has always lost money and is now dead. The end result is an email to its customers:

But why do software startups like Kettlebell fail?

That is a fair question. And after helping startups for the past 16 years we have some idea about what works and what doesn’t. Let me try answering that question today.

But before I do I’d like to share an amazing study done on 339 failed startups (and counting). There is so much to learn from these stories and after finding this I ask all my new startup customers to read through them. In entrepreneurship failure is the key to making it big, you fail, you learn a way of not doing something and you move to the next things slightly better at what you do. And what better way than to have a list of why and how others failed - it’s almost like a shortcut through the fail -> learn -> success route (although I think there’s no shortcut in that game :( ).

Source: Top 20 reasons startups fail

OK, back to my original question about why software startups fail and also how we can address that reason. I’d like to use another great article from the same data set where the researchers have tried to go through the stories and pin down the reasons and create a graph of the reasons. I share that on the side to give ourselves a reference based on data. I list our own list of reasons from our experience below, some of which map pretty well with the graphic and some don’t that much. But it’ll give you food for thought.

Forgetting the main goal of a software

Every successful software platform solves a particular pain point. Even Facebook solves a problem (creates others on the way though :) ) of staying in touch with people busy in their daily life. The success of the startup depends on how well the pain point is solved. Many startup founders lose their way during the build out process of a startup and start trying to solve too many things at once or sometimes imaginary pain points that has no use. Having a clear goal about the pain point that the software will solve is essential for startup success. This maps very much to the #1 item in the list above “no market need” - since not solving the pain point leads to exactly that.

Spending too much too early

No one has the crystal ball to tell the future and no startup founder knows what will work and what will not. You have to start with a hunch or a niche and then figure out how much of your initial idea actually was useful. So spending most of your budget on the initial idea, without leaving enough for the changes that need to be made for sure down the line means that the startup never gets the chance to meet the need in the market and dies. Again this maps well with the #2 in the data - “ran out cash”.

Obviously if you plan well you can make your money go a long way and get more out of it and thus get more done all the way through. Being smart with money is the most essential skill in startup leadership. KettleKitchen in my example above died after burning through 30 million in investment and millions in revenue it was earning itself. The fact that it survived for 11 years mean it had something going for it, lack of money management is what killed it.

No wonder a lot of smart startups use software teams like ours to keep their cost in control. They can dial up or dial down the cost as needed as they try things out in the market place. And using a company like ours which offers great rates because of the fact that we are in a low cost country makes a big difference. One of our all time best service product is the “Launch under 10K” we offer to startups.

Getting a software team that’s not a good fit

This is a big one. At the end of the day, whatever idea you have, however much focused you are about your goals if you don’t have a great software team that fits with your work culture and your way of doing things your startup will always fail. So if you are hiring, spend a lot of energy in the hiring process, since you’ll be stuck with this team forever and you make and break based on this team. If you are getting an outside company like us to make the software for your, spend time to find out if the outside team is a good fit for you and your product (and not just the price they are offering). Check out our great little post about this topic: How to select a software vendor?

This is #3 in the list based out of the stories above.

Not having a price for everyone

Every restaurant you go to you’ll see that they have a range of prices. Why? Because they don’t want to turn customers away just because it’s too pricey (or too cheap!). Same for software products, not having a range of options to fit different software budgets is a common mistake. Remember you can always upsell but getting the user to try your product and get to know it is a big deal for an unknown new startup. So have a range of packages, and always, always have a way that the user can try it for free - maybe a free 14 day trial, maybe a free basic edition. That’s essential to remove the barrier of “I don’t want to spend without know if this is what I need”.

Waiting too long to get the “perfect” first product

This is the other big one, especially for first time entrepreneurs. They just won’t release something that’s not perfect. Perfection here is what they have in their mind - an unattainable beast formed out of a hundred other software that the founder has seen, a mixture of Steve Jobs and Bill Gates videos about how software should be and sometime even a book on design. Waiting too long to release your product is sure way for death in this fast paced, fickle reality of the Internet, short attention span and crowded app producers. You just can’t wait, and not only because you want to get things out before your competitors do (or before your marketing message is lost) but also because you need to experiment and find out what you need to change, what you’ve got wrong. Release early, get feedback early, release often.

Not giving enough thought about your UX

With the wide choice out there for users sometime it takes a single bad interface element to put your customers off your product. If startups focus only on the engineering or the features and think of UX as an afterthought thinking that the utility of the software is enough to make it big they are making a big mistake. No software is that important or essential anymore in this world. Sometimes you’ll find great startup success stories that just had very little features at the beginning but good user interface to attract and retain people as they put the features in gradually. I remember using Hubspot when it first came out and thinking it has nothing but look at it now as a business. User UX and that includes the onboarding makes for a successful software startup. Read our UX cheatsheet for startup founders.

Jumping in too early

“Unfortunately, the VR market never developed as quickly as we all had hoped, and we were definitely ahead of our time. As a result, Vreal is shutting down operations and our wonderful team members are moving on to other opportunities.”

— Founder, Vreal

With all the hype about the “first movers advantage” many startups feel that it’s never too early to start something new. Yet from our experience you can always start too early, it’s actually hard to be too late! When you are too early on a technology you might have spent up all your budget before you see any revenue, or adopt users or even get any media interest. Take this quote from the founder of a VR startup that failed, Vreal

It’s much harder to fail because you came in too late. Coming in late means the technology and the mass users have ready to accept your product. It’s easier to find what others have made mistakes on and get your product to be launched without those mistakes. It’s easier to market too. Sounds weird, but it’s true. This is why Facebook wasn’t the first social media mover, it’s why Lyft and others still make it with a fight with the uber elephant in this space.

OK, I’ll finish today or this will start getting boring. I’ve put in my top ones above. There are other smaller ones, but if you can fix the ones above you are on the way to success. Starting up a new software business is the most exhilarating and fun thing in the world. Do it! I wish you all the best!

Our top tips for startup product strategy

During the past 16 years (and counting) of our work with hundreds of startups and small businesses we have come across a lot. We’ve seen single students starting with almost no money but amazing skills and dedication make a simple idea become a great success (with a little help from us). We’ve also seen very senior and experienced groups with loads of money with really good software idea fail miserably (and taking us down with them).

Startups represent about half of our everyday business. So they are super important for us and we just love working with them - for the energy and optimism they usually bring, for the quickness in their decisions and the cool technologies they work on. But every new startup we meetup we try to warn them about how difficult the path in front of them are and share our ideas about survival and things we’ve learn works really well for startups. We’ve written about many such tips in the past, here’s a popular one about 5 things that the founder should keep in mind One thing we see a lot is that many startup founders are all over the place about product strategy - how they are going to put up the product, what should they focus on to bring in more customers, etc. Here’s a short list of such strategy advice we share with our customers. These are tips that we know works 100% of the time…
 

Make sure you know the pain point you are solving

Every new technology is (or should be) to solve an existing pain point. If there is no pain to solve, then the new technology and startup that is making it will fail. So first make sure there is a pain point that your solution solves and know it well. That should be the sole focus of everything your software does.

Keep things simple

Your software will be new to users. It’s interface and probably all of it’s features are likely to be alien to every user you manage to acquire. If you don’t keep things simple you’ll lose them fast. Don’t hide your features in complex interfaces with features after features. Show them one thing that you do well (your pain point solution) and only show that. Things like simple UI, obvious CTA buttons, easy to organize dashboards can make or break your software business.

Offer different levels of subscription

Making packages that are modular or subscriptions that offer features that expand upon the base level, allows your software to cover a variety of budgets. You should always, ALWAYS, offer a trial or free level so that the decision for the initial buy is without any barrier.

Offer integration with other applications whenever it makes sense

Your software is not the only thing that your user will use. Your application need to talk with other applications that your user will use. At the very least there should be an export feature of the data. Without the option to integrate or with the fear of locked down with a particular software most new users will decide not to buy.
 

Consider additional services

Always consider if there are any non software services you can include for added value. Things like 24/7 support, or initial customization, or free setup will give you a big leading edge. They sometimes become the reason why customers will take your software instead of your competitor’s.
 

Plan for a great customer service

Ultimately, one thing you know can set you apart from the competition is great customer service. Offering ways to interact with customers, answer questions and guide them to new solutions is a sure way to retain customers, and get new ones via word of mouth. You’d be surprised as to how many startups in out there think of customer service as an after thought (or sometimes not at all) - yet it’s usually the cheapest HR cost in the budgeting.
 

Analytics and data will help you show the right direction

For any new software it’s hard to find out what needs to change to make it better. The hard way to find this out is give it enough time to fail and let your customers complain and leave. A much easier way is to setup data analytics to keep track of the metrics and act on them. Setting up things crash analytics, google analytics for visits, on page statistics are extremely easy and usually takes less than 1% of the full effort of making the software, yet they are extremely important for the survival of the startup at it’s early days.
 

Talent is everything in software

I come across a lot of NDA (non disclosure agreements) in my work with startups with the next big ideas. And NDAs are good since it give both sides a sense of confidence in sharing information. But at it’s core I sometimes find a feeling that it is the idea that’s super precious and a big secret. I think that’s a mistake.

Ideas, are easy - “a dime a dozen”.

It is the implementation of it that makes all the difference.

And it’s the talent that makes the implementation possible.

This might sound controversial. After all if Mark Zuckerberg gave out his idea of a social network that can connect friends and family (and random virtual “friends” who might or might not exist) wouldn’t someone else have built Facebook? Or if Elon Musk told everyone about his electric cars wouldn’t GM be building something called Gelsa today? Not really, you know this right? Friendster (with that golden metric - MAU - monthly active users in the range 3 million as early as 2003) , Myspace, Hi5(?) are just some other equally social and equally good at making strangers friends were already around when FB cam along.

Source: MySpace’s Rise and Fall – A Timeline of Highs and Lows

Actually as late as 2008 when FB was more than 4 years old already, Myspace was the top social networking platform, and consistently beat FB in traffic. Facebook did little harm to Myspace's popularity; at the time, Facebook was targeted only at college students. At its top, when News Corp attempted to merge it with Yahoo! in 2007, Myspace was valued at $12 billion! And if you look at the chart here that shows visitor counts for MySpace, as late as 2011 it was fighting out ( and losing) with respectable numbers.

Myspace is definitely a story of how not to do things. There is a lot to learn from it’s demise and there has been a lot written about it, I urge you to read some. But I digress from today’s topic.

As for stealing Musk’s idea, electric cars are obviously nothing new. There working models even in the early 1960s! For a great video about a quick recap about this space check out the video here.

Anyway, getting back to my point, there was nothing unique or even new about FB or Tesla. They just made it right, their implementation was better than others.

If you look around you would find this to be true for almost any idea you can think of or any successful software startup you see you’ll find that the idea had been around, maybe no one built it or others built it but they built it wrong. Just check out Kickstarter the amazing quality, uniqueness and breadth of some of the ideas are just mind blowing. But how many makes it big? And when they do why? You’ll always find that it’s because of their implementation.

And behind any good implementation is the team that build it. So using simple logic we have:

Talented team -> Great implementation -> Success

This may sound obvious, but you’d be surprise how many startups gets lost in thought that they have the best idea in the world and whatever team works on it, they will make it a big success. I would strongly argue the other way and say:

Hire the best team -> Think of an idea -> Success

OK that probably doesn’t work for a lot of startup owners since obviously its idea first for most founders. But if you believe in that formula of talent first you’ll probably morph into something like below:

Idea -> Hire the best team -> Morph the idea -> Success

That to me is the best formula for a founder thinking of making her ideas come to life. Oh, btw, I have the perfect Dilbert for today’s post…

How to reduce the cost of making a software?

As a custom software development company a common question we get asked is about reducing the cost of development. Software development is expensive. Even using relatively lower cost countries such as Bangladesh or Cambodia, a startup owner is likely to spend the largest portions of her funds on making the software. Yet software is only a piece of the story and usually the one of the first ones, huge costs waits for her in marketing and sales that she has to budget for. Hence cost optimization and reduction is an important strategy for the software development, and if done right can be a deciding factor for the success of the startup.

Here are some strategies we suggest to startups (and even established and large companies) to manage, optimize and reduce their software development costs:

Use an outside development company

Salary cost, particularly development salary cost takes up the largest regular cost of a company. An in house software team is invaluable, there is no question about it but when budgeting becomes tight, using an outside development team that can be dialed up and dialed down on short notice is the single best move a company can take. This gives them immense flexibility to adjust and control the cost on a regular basis and defer the risk of financial commitment of an in house dev team (which I think is essential once the software and business is established).

Source: Inc article

The graphic here shows the social sharing and marketing company Buffer’s average monthly costs. Thanks to Buffer’s open book policy this information is available for a live 7+ million dollar annual revenue company and will give a rough picture of how the costs are laid out. As expected about 69% of cost is spent on salary (for 64 employees when this data was taken).

In case of this example, the company has already produced its flagship product. The initial time when the product was being built would incur a much larger cost. For many software projects and startups this initial injection of fund can a big problem or might lead little or no funds for the marketing effort that will follow the launch of the product.

Finding good software development vendor and utilizing that vendor in an optimal way can give startups a huge edge over its competition yet keep the overall flexibility in its business operations.

Advancing the project tasks by non developers

Many software project tasks can be done in house by the founders or members of the existing team. Getting these tasks done would mean that the total effort by the software development team (in house or outside vendor) would be reduced. This leads to higher productivity for the team and obviously less cost per feature.

A great example of project tasks that can be done by a founder herself (or non developers in the team) is the creation of initial product ideas and wire frames. Sometimes founders approach dev teams just a list of ideas say in an email, this means the development or product team has to work to turn those into usable specification. This requirement analysis cycle can be quite prolonged if the founder or key stakeholder hasn’t fleshed out the ideas well and has to go through prolonged sessions involving members of the technical team or the outside vendor. The whole process can be fast forwarded and compressed if the founder can think through the ideas and use an easy to use mockup tool (our favorite is of course balsamiq ) draw out the ideas. The whole requirement process then gets cut down by as much as 80% in our experience.

Non development stakeholders and founders can also help out on many other areas of the software development process like testing, helping with documentation etc. All of these add up to create substantial reduction of costs for making the software.

Keeping the requirements stable

One of the biggest way of increasing cost of a software project is feature creep or constantly changing requirements. When a software development team has a clear specification it can plan and implement the features at a very fast pace. But as soon as those initial specifications start changing or new features start creeping in (because “business demands it”) the cost of rework and changed priorities will also pile up. Over time this single cause lead to cost increases by 100-200% if not controlled in our experience. So this is a single big area to be concerned about and control to keep the cost of software development under control.

How to make your own software product by yourself?

The world of entrepreneurship with software solutions is challenging to say the least. Software is expensive to make. Software is difficult to make right. And above all it’s super hard to know if the software you are making is ever going to make you any money. With such risks involved it is always a very hard decision for cash strapped startups (that don’t have a few billion to spare from VCs) to turn their ideas to usable software. In our everyday business of making custom software for our customers a large proportion of whom are startups we get asked the following type of questions a lot:

“Can we make our own software without any coding skills?”

“Can I learn a bit of Python and make this at home?”

“How can I make a prototype to test my idea?”

“Is there a way to make software by myself?”

Although as professionals our first reaction is always to say “no”, but in reality the answer is not so straight forward. In most of cases the answers are probably “yes, but …” The “but” is from the knowledge that getting a customized software solution done without any coding skills is very difficult. However,

it is not impossible

Actually our realization is that in many a cases it is the better thing to do, the better business decision and a better survival idea for a startup. In our experience, here are some of the situations where a founder should invest her time and energy to find out if the first version of the product can be made at home:

• When cash is too low for using a reliable vendor.

• When the idea is to vague and the business case not clear enough.

• When the app’s features and UI feel like something that is very common.

• When all that is required is a quick prototype to get feedback.

In situations like the above, a founder can try making the software himself to get at least to a prototype that he can show to others, to potential users, to possible investors. She can also try out the idea on a small scale, like with her own friends and family to see if this would ever take off. This is of immense value to validate or discard ideas and more importantly to pivot on the original idea to something that would actually work or sell - a fact of life for every idea in this world. Remember, the great Facebook started as a “hot or not?” site for Harvard students ? You just don’t know how much of your idea will change to become a real product that people use or really need. And this process of finding out the changes and pivoting is extremely expensive that most startups find impossible to cross over and great ideas die. Having the ability to do these tests, failures and pivoting at very low cost (mostly of the founders’ time and energy) is really a big thing. And even the act of trying to make the software is a very good learning experience for the would be software owner. It gives non technical founders a feel of what’s involved in the development of software, the challenges and the reality of getting things done.

Great, so how do I make my software again?

Source: Stackoverflow developer survey 2015

:) Well a non technical person can always learn a programming language. Coding isn’t really that difficult as its sometimes portrayed to be. In a survey done by Stackoverflow (probably world’s top most coder forum these days) almost of half the coders didn’t have any formal education in programming and they were self taught - 48% of respondents never received a degree in computer science. And we are talking of top professionals in this field.

So learning to code and using that knowledge to make your software is definitely a feasible option. It depends on how committed you are, how much of knack you have for picking up new things particularly technical things. With youtube videos on practically any coding platform in the world or online tutorials and course on sites udemy or couresera anyone can become really good at coding.

The other thing to remember is that programming languages and platforms are getting much easier. The days of C/C++ and black terminals running weird text editors and magical incantations of “greps” and “emacs” are long gone. Most programming interfaces are super user friendly these days and the programming languages are forgiving and less ominous. On top of that there is an advent of visual drag and drop like programming interfaces that takes care of hiding the actual language from the user.

But how about NO CODE?

The nice thing about technology is that it is always expanding. So as time goes by more and more technology is coming up which let’s non technical people create software easily without even learning any code at all. There is a whole family of these “No Code” platforms available now and new ones coming out often. Google will be your friend for this, a search with “no code programming” or similar would give you links to such platforms and videos to give you preview of what’s involved. Some of them are very powerful, to the point that we have started pointing them to people who are interested. Here are some that looks promising:

GoodBarber - No code mobile applications creator with free trials and loads of tutorials. Good for eCommerce apps and if you are thinking of content heavy apps. Really worth exploring before you spend any money on custom dev.

AppSheet - If your app has a lot of data that needs slicing and dicing or lists that needs to be displayed, this is an interesting platform to explore.

AirTable - Has hundreds of templates to start your data heavy apps that can integrate with other APIs. The promises are amazing, but we’ve never tried this out yet.

I’ll finish with my customary stolen Dilbert - a nerdy sideways jab at non techies maybe, but funny nevertheless :)

How to find a good software developer?

Finding good software developers is probably the most important thing for any software venture be it a micro startup, a giant bank starting a new project or software company like us adding new developers to its team.

A good developer makes a software possible, it’s as simple as that. You can find a developer (there are millions out there just go to any jobseeker or freelancer site) with all the certificates in the world, you can pay him well, you can give her the more time than you had planned for, you can give him the best tools that money can buy but the output - the software she makes depends only on one variable - is she good at what she does. In most other professions as long as you get someone who has been trained to do his thing he will get the job done at some point - some faster than others, some better than others but the job will be done. But with software the number of years of training or the number of framed certificates is in no way a guarantee that your software will be made. Some people can make software (without a single certificate on his wall) and others just can’t.

Given this situation, finding a “good” software developer is critical. But how do you find one? How do you know that someone is that “good” developer? Not easy questions to answer and even after 16 years in this business of finding developers we get things wrong sometimes, but I’ll try to share some ideas that might help.

1. Good developers are “get the job done” people

The first thing is to define what is “good”. The easiest is to say “good” software developer is someone who gets the software made :) But we would not know that right at the beginning when she hasn’t had the chance to make the software (and we definitely can’t wait for the project to fail and find out she wasn’t our choice after all). So let’s define “good” based on qualities we are seeking in a coder which we can somehow test:

Good is someone who gets the job done.

“... the duct-tape programmer is not afraid to say, “multiple inheritance sucks. Stop it. Just stop.”

You see, everybody else is too afraid of looking stupid because they just can’t keep enough facts in their head at once to make multiple inheritance, or templates, or COM, or multithreading, or any of that stuff work. So they sheepishly go along with whatever faddish programming craziness has come down from the architecture astronauts who speak at conferences and write books and articles and are so much smarter than us that they don’t realize that the stuff that they’re promoting is too hard for us.”

— Joel Spolsky

In our profession you’ll find many (too many in my opinion) who are at the level of a University professor with deep theoretical knowledge about design patterns or Java history. You do not want them. They are going to waste your time by thinking too much about what’s right and what’s not. You want someone who might know everything about Java but can go into a piece of code, use google to find answers to his questions and put in a band aid like fix without any guilt complex about his lack of knowledge! You need someone who gets the job done. Someone who can play a multi-hatted role in the everyday business of software development. Joel used to call these rare people the “duct tape programmers”. A good read in this line of thinking is Eric Sink’s superb little timeless piece You need developers not programmers.

2. Good developers are not afraid to write code in front of you.

“Would you hire a magician without asking them to show you some magic tricks? Of course not.

Yet, every day, programmers are hired on the basis of an impressive resumé or because the interviewer enjoyed chatting with them.”

— Joel Spolsky

You hire developers to write code. So it is a very natural expectation that they should be able to write code right in front of you, right? You’ll be surprised about how often great resume holding (and of course certificates… OK you get my irrational bias against certificates…) people will just be too scared to write code in front of you (say during an interview). Or they’d just be all over the place with the code and come back to say something like “this will need to be refactored of course” or something fancy like that. Run. Run like mad from any developer who can’t start writing code at a moments notice. Good developers should be better at expressing themselves in code rather than in language.


3. Good developers come with references

Joel Spolsky

Author of the best blog in the world for software development experience www.joelonsoftware.com

This one so obvious that I won’t delve too much into it. But leave by saying that before a developer is called the quality of their reference from someone you can trust (rather than their resume) should be the big marker. You see good developers easily make themselves felt. So every manager, team lead, business owner knows who is good very easily just from experience. Because they have gone through and got (or did not get) their software. Only downside is most manager don’t want to lose their good developers and want to get rid of their bad ones, so you got to be careful about whose words you trust! Our trick has always been to find our own references from peers rather than bosses.

4. Good developers are found in forums

Good developers are often found lurking around in tech forums asking and answering questions. Stackoverflow is definitely the big one, but there are many others. So finding links to their stackoverflow status or contributions should be a good thing and similarly if you are desperate forums are a good place to seek these rare individuals out. Microsoft is infamous with this trick, we’ve lost several of our super stars with MS poaching on them all the way from Redmond. Imagine getting a call from MS one night? Who can fight with the gods? D… the Internet :(

OK before I lose it I’m off. Hope you find your good developer and if you can’t just get us to build your software for you, we are best after all :p

5 things software entrepreneurs must remember

Having a great software idea in your head and a fast moving software team to make that idea a reality is what it must be like to be on drugs. It’s addictive, it makes you stay high and there is nothing in this world that you can quite see with pessimism. This is what makes software entrepreneurship so attractive, this is what makes thousands maybe even millions give up their jobs and jump into this unknown, knowing all the risks and odds.

But beyond all the known risks there is an enemy that is always lurking– and very few people recognize it. If not recognized this enemy can kill.

The enemy is within. It is your enthusiasm! Yes, the very thing that makes the start-up successful, the experience amazing and that fosters innovation can also if not kept in check destroy everything.

Kaz, as a software development consultancy, that works with early stage start-ups and their highly driven owners and leaders, we’ve seen that enemy many times. And we have helped our clients tame this enemy and use it in right direction for the right causes.

Today I will list the top 5 reminders we give to our clients - to keep that enemy in control.

1. Remember that the app will solve only one thing.

In the mind of the owner the original idea of the software evolves and starts to become something that can solve anything. Maybe it can, but time and money both are limited. And the urge to add yet another feature to cover yet another use case can derail the software building process and eventually delay things enough to make the app fail.

The only way to keep things in control is to remember that however great the app, it will probably solve only one human pain – that is the most important use case and everything else can be discarded. The focus should be only that single use case, and release with that use case.

We sometimes suggest our clients to have the use case put into a single sentence, print it out and paste it in front of them somewhere visible.

2. Remember to compromise

A piece of software is all about compromise. You have to compromise on features, bugs that need to be fixed, delays you have to accept – the list is endless. By knowing when to compromise and on what, you make development process smooth and meet the deadlines. And most importantly for early stage startups get the release up where people can start using it.

For entrepreneurs, their idea and thus the software is like their own child. This makes it very difficult to compromise. In some cases, we’ve found, they forget that it is good to compromise. They start treating compromise as something evil. And this has huge negative impact on delivery schedules.

Remembering to compromise is something that makes the difference between a software out on production box and a software in an endless loop of fine-tuning in the dev box.

 3. Remember to trust others

Software requires collaboration. A single person cannot get everything done to get a software from ideas to reality. And collaboration implicitly requires trust.

Normally a software group can easily create trust amongst its members (obviously things can go wrong, but that’s because of some real problem in the team). But in a start-up scenario, especially in its early stages, sometimes the owner can find it difficult to form that trust relationship with her developers. The cause, I think, is because of the constant feedback she gets from the team about the time it might take get certain cherished features done, etc. As harbinger of bad news, typically the team lead may seem to be the person who always dampens the spirit. This can sometimes make the owners difficult to trust the lead or the team. And if that happens everything suffers.

Teaching herself to trust can be one of the best things that an entrepreneur can do to help the team. When we face circumstances like this, we try communicating this in various ways. Not being Dutch and not having the wonderful ability to say things directly makes it difficult for us! But our way out is to do it in little steps and also to involve the owner more with the actual development process so that she can understand things better.

4. Remember that the software is for others.

This one is the hardest to remember. The entrepreneur lives with the idea and process of software building with such focus that, we find sometimes, she forgets that the software she is building is actually for someone else – users! Remembering this important, knowing what your first customers are like and that the fact they might have completely different persona and requirements than you keeps the feature planning and decisions on track. What you may value as important may not be what your average users would value so much.

We suggest doing a regular thought exercise where a question starts with “When user Mr. X uses this feature…” to our customers. This sets the context and understanding that the software need to be viewed through the eyes of a typical users. Our interaction designers are big on Alan Cooper’s user persona creation process and we have found that including the owner with that process helps immensely to disassociate herself from the target software users.

5. Remember that there is a tomorrow.

Owners sometime forget that software has the possibility of versions. What we cannot achieve in this version can easily be added to the next version. Splitting up the features into versions and phases is the essential software project management activity.

Sometimes it’s hard to push cherished features in the back-log, and owners feel like that they have to cram everything in the next release. If the next release is the first one, this is most painfully felt. Remembering that there is a tomorrow that a new release can be done pretty soon – even really the next day can help a lot.

5 points for deciding to outsource or not your app development

You have an idea for a great software or an absolute need to get an app done to boost your productivity, but you don’t have software developers. How do you make your app? Do you hire developers or outsource it to a bespoke software development company?

These questions are not easy to answer. From our experience in this space for more than a decade, here are the top 5 things to consider.

DO I HAVE THE DOUGH?

Do you have enough money to hire in-house developers and also spend on marketing?

If the answer is yes then it’s a strong reason not to outsource. We’ve got to be honest here, having your own developers working next to you is the best, if you can cover some of the other risks around this. But you should also consider, if it makes sense to get more mileage out of your funds by using a lower cost source or if you want to spend more on marketing, keeping the development cost in control.

CAN I MANAGE TECHIES?

Do you or your in-house team have experience managing a technical team?

If you answer yes then that’s perfect and you will need that experience whether you outsource or hire internally. But if you answer no, then that is a big reason for outsourcing your project. As anyone with experience in the software world will tell you, software project management is a pain (and also an art). With an outsourced project, if you choose the right partner, you can also outsource that pain to someone else! Set the milestones and your delivery expectations, reasonably, and it’s the job of an experienced project manager to get those expectation met.

HOW SPECIAL IS MY CONTRAPTION?

Is some unique algorithm or convoluted calculation the main business value of your application?

If you answer yes then this is a strong reason not to outsource, at least that part of the software which is unique. When you outsource you don’t have direct control over the resources and a developer who might have the whole algorithm figured out in her head might just leave and it’s very difficult for you to stop that. Also, business sense says that the knowledge should stay in your control. Google wouldn't be google if they outsourced their search logic!

The solution could be that you hire developers for the core and save money by outsourcing the the rest. Or you could have a contract which lets you have the option of hiring the resources at some point.  Here is something that we sometimes have in our contract to cover this situation:

“...Acme inc. may request Kaz Software to place named team members as direct Acme inc. employees, with the express prior written consent of Kaz Software...”

CAN I GET ALL THE SKILLS TOGETHER?

Does your in-house team have a variety of technical skills?

Software requires all sorts of skills. To start things off you need a variety of ideas in your brainstorming so that innovation can happen. Then you need designers to draw things. You need technical people to say what’s possible, what’s a good trade-off (“oh that will take years to support on Internet Explorer”) and you need them to write the code (of course!). Then you need testers to check if there are bugs and systems guys to find the right server to deploy and launch the product.

When you are using an in-house team, usually you have to get by making the same person to put on multiple hats. This may work but it limits the set of ideas and possibilities. When you outsource, you usually get a pool of resources from which people can be drawn into your team at the right time and then moved out. This is a big one for going the outsourcing route if your local team is small or non-existent.

HOW ROCKY IS THE ROAD AHEAD?

If you have a business plan and the market research that says things should be a sure shot then going in-house works. But if you are not sure and know that the road might be rocky ahead then having development outsourced is much safer - it lets you ramp up or ramp down fast. With an in-house team both growing and reducing fast is painful and expensive. And having a reputation of that instability makes it that much difficult to hire talented techies from the market.  

Worried? Don't be. At the end it's an adventure and if you play thing right a really good one. Contact us if you need our advice or want to consider us for developing your app. We have loads of experience helping customers like you. 

Contact us for free advice

Contact us for free advice