I have gotten too many SOS calls from entrepreneurs up the software creek without a paddle. It’s time to talk about a few practical ideas on how to get the right technical help for your new software project – and a few cautions to avoid.
It was not three months into my first dive into solo software consulting. I agreed to a phone call with a contact that reached out to me via LinkedIn. After the introductions, here’s what happened to the best of my memory.
I was greeted by a team of two co-founders chatting with me over speakerphone. They quickly told me that they really needed some help and guidance. Then they told me a tragic story that I had heard too often even back then.
A while back, they had a great idea. They realized that if they could get their idea built with software, they would be able to build a business and maybe achieve the life of their dreams. There was only one problem – neither had any idea how to build software.
They told me they were able to secure a small amount of funding from wherever they could. Soon, they had enough that they started looking for professional help.
All too soon, they found out that software development is expensive.
They kept looking and found that developers from other countries could build their app for much less than their US counterparts. Soon, they were ecstatic- they were going to get their dream app for a fraction of the cost!
Shortly afterward, they began working with a freelancer from overseas. They explained what they wanted, and once they began paying he began development. They would meet often and he would ask his questions. Then he would disappear, do his work, and reconnect when he had more questions.
With time, he came back with the first part of their app. Finally, they would be able to see it!
Immediately, they saw it needed more work. It wasn’t as visually appealing as they hoped, and worse as they tried to use it they found that almost nothing really worked as it was supposed to.
They chose to be patient with the process. They reported the bugs. Over time, things got fixed. They told themselves that they didn’t have many other options.
However, each time a new release happened there were also many new bugs. Even when bugs were under control, the flow of the app was confusing and difficult to use.
Eventually, new releases started to introduce bugs that had already been fixed. They had to pay for more and more fixes out of less and less money. It was so time-consuming for them to find and stay on top of so many bugs. They lost confidence in their hired help. They wished they never hired him in the first place.
They felt they were expending every effort yet going nowhere. In the end, they fired him.
Now, they were in a real bind. They had a deadline approaching, very little money left, and their app still didn’t really work. They reached out to me for help.
I couldn’t personally be their new developer. I explained that I was already working more than full-time as CTO for another new enterprise. It would be too much for me to keep my commitments with my current company and fix their app at the same time.
All I could do was share my thoughts on how to move on and avoid a similar catastrophe in the future.
This experience has stuck with me. I’ve spent years thinking about what may help entrepreneurs avoid that fate. Frequently, others reach out with a similar story, and every time I hear it I feel like something should exist to warn people of it.
To me, here the crux of the issue. How do you judge the proficiency of a self-professed professional when ignorance of that domain is your principal motivation for seeking help?
I don’t have perfect answers to these questions. But, I hope some of my opinions might help a few of you to find your own answer.
Don’t begin the software development effort prematurely. In my experience, it is better to build and get running the marketing and validating sides of the business BEFORE beginning software development.
The best engineering talent available will not help you if your team is solving the wrong business problem/builds the wrong thing. In my opinion, this is the most common cause of failure for businesses that never even leave the runway. Here’s an idea of what you can build as a first step instead of your app Link first article.
Business development is more important than software development
Once you have many successfully found and paying customers asking you for software solutions to their problems, then there is plenty of time (and sometimes more budget!) to begin development. If no one has yet paid you, there are likely more important things to be working on rather than software.
There are a whole host of resources on this mindset, but here’s one of the most prominent as a summary The Lean Startup.
Respect the difficulty of identifying suitable talent in any field. Many companies large and small keep a constantly revolving door of workers. No matter how much money, research, perks, or anything else contributed people still quit or are fired from time to time. Accept that you may and likely will make a few mistakes along the way.
When seeking early technical help, I’d first seek reliability. I recommend it over the impressive, cheap, quick, or even the most proficient.
If you want reliable results, investigate what reliable software development looks like. The above story had many signs that could shout WARNING before you use all your funding on a solution that may fail you in the end.
There is no “one way” to create reliable software, but there are many widely accepted best practices. Here are a few examples.
One is defining and requiring a formal definition of exactly what a “done” task means for your project. This is generally a specific checklist and a good idea to include in a contract if there is to be one.
Another boon to reliable software development is the consistent use of a task organizational methodology. This gives you and the developers a way to view the priority and status of the tasks and project as a whole.
Ideally, you should be able to look at a centralized place at any given moment and know exactly what your developers are working on and why they’re working on it. Two common examples are Kanban or Scrum.
Know that there are many different roles that go into a successful software project. By volume, most developers fairly specialized in a few specific areas.
Your first concern on a new project is to find a generalist who can help you accomplish the end-to-end software development process. You will be looking for someone with experience in software planning, budgeting, hiring, and overseeing project development.
Second, you need someone to oversee the technical architecture of your project. This person must have sufficient technical skills to know if a proposed solution will scale adequately for their use case, which systems to choose for your software, and how to maintain a healthy codebase.
If you’re lucky, you may find the technical and team leadership skills in the same person.
Together, these roles create your technical leadership team. Beware of engaging additional help without these trusted parties already established. Without these roles being well-staffed, it is difficult to distinguish good help from the bad.
The best-case scenario is if you are able to confidently hire your technical leadership as part of your company. However, you can also consider a freelance or consultancy offering to fill this role.
Once you have your technical leaders, you can then consider the best way to get more developers to move your project along faster and cheaper. If you have adequate technical leadership in place, it is less risky to explore cheap alternative sources for developers.
If you try to hire a consultancy or freelancer directly and trust all technical needs to them you are more likely to lose your money than get a usable product. However, if your technical leadership comes from a different source than your help they can act as checks on one another.
Did you know that the exact same application is usually built completely differently if 10,000 users are expected vs just 100? It is important to have at least some idea of how “big” your app might get within a few months of your initial launch.
In general, you want your development team to clearly define a plan for scale appropriate to your expected users. You do not necessarily need to build the version that will scale to all your potential users immediately, but you need to be sure that the overall software system is built with your goal in mind and that you stay ahead of increasing adoption.
The exception to this is if you are purposely building a proof-of-concept application that will be rebuilt in the near future. Completely ignoring scale concerns can cause a complete re-write much sooner than you may hope.
Consider enlisting short-term help when seeking your technical leadership team. If you know any experienced developers, you may be able to convince a few to help you screen potential candidates or consultants. You can have them look over the projects, review credentials, or help you interview your intended developers.
This can be a surmise other points above – give yourself as many tries as possible. If you can minimize the cost of failure, you have more opportunities to find what works.
In practice, communicate early about items that are not working for you. If they don’t improve, consider hiring alternative help as early as is possible.
Hopefully, you’ve been able to apply something mentioned to your own situation.
Best of luck on your own software adventure!