Consider landing a plane. You, the founder, are the pilot. You’re cruising at a high altitude. You have to make a lot of decisions quickly to move into “landing” mode. Drop altitude by a certain amount, keep all things copasetic while doing so until that plane (your business) smoothly touches ground. Anything goes wrong here, so does the landing. As an entrepreneur to a new startup, the analogy is eerily similar.

One of the key things that get missed as you, a potentially non-technical founder want to consider when looking to employ a company to engineer your software product is to create a stakeholder document. Most importantly, what is the goal of it that document? Let’s get back to that pilot analogy. What is the highest arching goal? These goals ultimately inform those features you implement into your software as you get near to the landing site.

For example, let’s say you are creating a telemed application due to the recent events around the world. Your goal may be “to help those in need of medical assistance gain access through virtual visits”. A parallel goal could be to draw in revenue while you provide this service. After all, who doesn’t have bills to pay or investors to address? You'll start at a 60'000' view.

60,000' View

A high-level stakeholder document helps to identify who those decision makers in your startup are and what their responsibilities include as you hover in the air with this software engineering firm. So say we’re at your highest view, 60,000 ft view as the pilot, software firm XX is co-piloting beside you.

As you begin to work with a vendor like T-Minus Solutions (we'll call them your stand-in CTO for this exercise). Too often, you can get into a contract with a software engineering firm with too loose of topics and terms inside that statement of work. Operating without a stakeholder document can cause many headaches later.

‍

40,000' View

Now’s the time that we want to lower to a 40,000 ft view. You of course, still as the pilot, want to ensure that the software proposal they provide you is aligned with your goals from the key stake holders exercise. If that firm you’re looking at hasn’t outlined pretty considerable feature sets by this point in the conversation, you can usually start to sniff out a future problem.

You want to get intimate before getting even the “proposal” or statement of work.

A good software engineering firm then goes into a design-level document. This would include things like user workflows, manual steps and process, “who” is doing this, screen designs … UI/UX design discussions.

20,000' and then the 10,000' View

From there, we get into more details, going down in altitude to 20,000 ft, major features. Through that process, you begin operating at a near 10,000 ft altitude.

• Planning Phase (Stakeholder Doc, Statement of Work)
• Design Phase (Taking Concepts, Ideas, Goals)
• Build Phase (Building back-end and front-end)
• Release/UAT/Launch Phase
• Monitoring Phase (on-call)
• Bug Fixes/Enhancement

Anyone building software should know there are typically two major parts.

There is a chunk of code on what's called the “back end". Then there is a second chunk of code on what's known as the "front-end". The front-end is what shows to the everyday user. When people do specific things to take action on the front-end website, they call in to the back-end of the house there to execute those actions they requested in the front-end. These two major parts talk back and forth to get and give information like “new customer just signed up” and then what the customer gets like a transactional email “thanks for signing up!” and how that is branded, etc.

In selecting a software engineering firm, you should expect milestones that are set up to demonstrate certain portions throughout the development phases. One demo a month is a good cadence. Internal testing happens periodically throughout development. Then you shift into “user acceptance”. It’s now your turn to get in and beat up the software. You try to break it. You try to ensure that it’s actually working as you expect.

Now you want to start thinking about “beta” phases so that you can test the market before publicly announcing to the world. Finally, when you are ready to launch, you'll want a mission control team set up to address any bug fixes immediately as the product lights up and makes itself known to the world.

Once the initial launch is over, you move into a monitoring and maintenance mode, as well as planning for big new feature updates.

You are always welcome to consult with the T-Minus Solutions team to best understand how to find the right software engineering firm for your business.

‍