Picking Your Software Partner
There is an entire army of “engineers” out there who don’t know ANYTHING. They’ll tell you EVERYTHING you want to hear, take your money, and build you shit. At least once a month, I get the following story. I hired (Insert random country) to build me X. They said it’ll take 3 months and cost $12,000. It’s been a year and a half…I’m $150k in…. It’s almost working, it’s just Google Maps isn’t loading the data…. Please help…
I take a sip of coffee and ask to see the code. 99% of the time it’s unusable. Unfixable. Bad architecture, built by idiots, will crash when you get 100 users on it. Have to redo from scratch. The reason I write this real story is to remember step number 1. Picking your software partner is a lot like finding your spouse. It’s really hard to find the right one that will fit your needs, budget, and goals. You might have to go through a lot of them to pick the right one, but when you find them, it'll make life a lot easier.
When you’re researching, ask questions and get answers that you can understand. What’s the plan? How
is this
going to work? If shit breaks at 2 am, are you answering the phone? (It can happen). If the answers
are not as
understandable and blunt as what you’re reading now… run. Don’t give anyone a dollar you’re not at
least 99%
comfortable with. You don’t need to understand the technical details of how things are built (I
mean, your job
is to ultimately sell or incorporate what we’re building), but you should be comfortable with the
person giving
you answers.
The Document That’s Not Egyptian Hieroglyphics
Software engineers are not mind readers. You’re more than welcome to have a conversation with us
about what
you’re trying to build, but until you write down details, those conversations are more or less
pointless.
The document that you end up writing will serve as the first blueprint to get a plan of action
going. Once you
have a document going, you can get an idea of how much it’ll cost to build your thing. BUT PHIL, how
do I write
a document?
In any way you want. People often ask for an example document, and I used to send them one. Then
they would fill
it out and I was even more confused on what they were trying to build. Some people draw boxes on
pieces of paper
and send me pictures, some people make video recordings showing competing software and what they
like/don’t
like, some people write bullet points. Whatever is easier for you. You don’t need to write out what
a login is.
I got that. But you should explain what happens after a user logs in.
Naturally, when you write your first draft, there will be a ton of conversations / questions
afterward. This is
normal. At this point, you shouldn’t have paid anyone any money.
Designs - What’s it Actually Going to Look Like?
If you don’t know what Figma designs are, now’s a good time to Google them. You don’t necessarily
have to use
Figma, but Step 3 is all about drawing the blueprint. What is your app going to look, taste, feel,
touch, smell
like, etc. Designs should cover 95% of functionality, and you as a non-technical person should be
able to look
at designs and have a very good understanding of what is being built. If something doesn’t make
sense, if it’s
not clear how something will work… ask your developer (or designer) why it doesn’t make sense.
If you are just starting out a piece of software, you should do the designs before you program
anything. If you
have a piece of software and you’re adding to it, let’s say a mobile app to an existing web
experience, it’s
okay to combine some programming work with the designs as the first milestone.
Milestone Deliverables
Some places charge hourly; I’m not a believer in those types of places. A typical MVP (Minimum
Viable Product)
project can take anywhere from 3 - 6 months to build. The idea of paying hourly before you can hold
any magic in
your hand seems like an illogical process. Now, there are exceptions to this rule, but if you’re
just starting
out, step 4 is all about milestones. Your developer should be able to outline what is going to be
delivered, at
what time it’ll be delivered, and how much money you’ll need to pay at that time. We usually do a
50% deposit /
50% upon completion per milestone, but that’s what makes the most sense to us.
Here’s a sample milestone completion schedule that I wrote:
Milestone 1: Design + Login, Download interact with preselected area on Map offline (no data from
server yet) (3
weeks backend, 3 weeks iOS + 3 weeks android) Completed in 4 weeks.
Milestone 2: Admin can draw area on map and assign to the Rep (3 weeks backend, 3 weeks iOS + 3
weeks android)
Completed in 3 weeks.
Milestone 3: Create contact (Pin), Schedule, Contact by Street, Custom Tab in Contact Details
(3
weeks backend,
3 weeks iOS + 3 weeks android) Completed in 3 weeks.
Milestone 4: Documents, Custom Forms, Search, Filter Full Completion
(4 weeks backend, 4 weeks iOS +
4 weeks
android) Completed in 4 weeks.
QA / Testing
At this point, you should have something in your hand that works from beginning to end. But that
doesn’t mean
it’s going to work for everyone. Different operating systems (especially in the Android world where
there are
thousands of phones) react differently. So now it’s time to test. Your development team/developer
should have a
QA. An individual whose sole task was to test before you got the app. You should make sure this
person exists
and that they tested your application before you share it with the world.
Afterward, share the app with everyone you know. Mom, Dad, Friends, and Grandma (if she’s capable of
using a
phone or computer). Make sure they use the app from beginning to end and everything works for them.
There are
services that exist out there that will also do QA testing for you. We don’t use them because we
have 2
full-time dedicated pro QAs on staff, but I’ve read they can be effective. (Be careful as there’s a
lot of data
farming fraud here also.)
Once you’ve tested with QA and a bunch of people, it’s time for the finale, moving to production.
Moving to production
The developer at this point should send you a giant laundry list of things you’ll need to purchase.
Your server
(where everything will live), your 2FA services (should your app need 2FA), where to register for
your Apple /
Android dev accounts, etc. This is how to take “ownership” of your project. This also should be
where the
developer takes all the code they wrote and uploads it to a repository (GitHub or GitLab are the
most popular,
but
zipping everything works also) and sends it to you. This is often called moving from staging (the
developers
technical environment) to production (the development environment for customers that you own).
Your project should be live on the app stores or you can go to your URL that you purchased and be
able to use
your
application.
Congrats. Now good luck marketing.
