Taking a concept and running with it

I’ve spent most of the last decade building technical prototypes, MVPs and other concepts and driving them forward. What do I mean by that? I mean that founders, project managers, product managers, CTOs, and so on have an idea or the start of a concept they’d like to take to market; that market could be internal and external. They want to build that concept out without as much risk as hiring an entire team to carry out the project.

So you have a great idea? How is that built out and taken to market? Let’s start with the basics. Here are a few questions:

• What is the timescale for getting this built?
• Where do you want this to run?
• What operating budget do you have?
• What software do you plan on using to develop the prototype?
• Do you have any in-house talent for development and maintenance down the line?

The above list isn’t all-encompassing, but it’s a good start. Let’s look at a few of them.

Timescales

Of course, most people will answer with “as short as possible”. Let’s put an accurate timescale in place. The software that needs to be deployed how close to working is it? Some people have a fully functioning codebase that needs productionising, and others have nothing more than a piece of paper with an idea. This, of course, makes a massive difference to realistic timescales. Then there is a speed vs cost trade-off to look at as well. We could hire a large team and throw loads of people at it; this will likely get things up and running sooner. However, if other aspects, like marketing, also need to run in sync, getting finished sooner may not always be better. Sometimes slower is better also because it gives you more time to make prototype changes and tweaks as elements are built, and it becomes clear that usability, functionality, etc, can be improved.

Runtime location

Most companies target the Cloud, but this isn’t always a hard requirement. Let’s look at a few different examples.

Banks. Banks are funny places; they love legacy software, often legacy hardware, in the name of security. Heavily firewalled and almost impossible to access, if you offer to run things in the Cloud, you’ll likely get rejected. Of course, this isn’t a hard rule; moves have been made to move aspects of the banking ecosystem to Cloud services, and banks like Monzo have recently moved the bulk of their Kubernetes processes to EKS, for example, a shift away from self-hosting.

Telcos are the same: hardware everywhere, private clouds and the love of OpenStack. It helps from a security perspective, and they are comfortable with it.

But in general, the world is happy with cloud computing; it allows you to run code without buying the hardware and makes it an ideal place to run prototypes and MVP-style deployments in a flexible environment.

Of course, picking your runtime target as Cloud or on-prem makes a huge difference to the tooling and workflow you use to build the prototype infrastructure. If you decide to target a Cloud deployment, the next question is which one? AWS, Azure, Google Cloud, or a different smaller cloud provider? There are many out there, and each has its pros and cons. If you already use a cloud provider, do you want to stick with it? If that means you have in-house talent to deal with your provider, it makes sense. However, sometimes you need something only a particular provider offers. Have you made the switch to using their managed service offering?

Then, where do your users reside? What regions and geographical locations do you want to run your code in? Generally speaking, getting it as close to the users as possible makes sense, but from a proof of concept point of view or even MVP, that level of scale and complexity sometimes doesn’t make sense.

Operating Budget

Next up, it is often quite important for those on a tight budget and those who want to ensure the project gets built within the confines of a spending framework and won’t incur spiralling costs. What is the operating budget? Of course, this can be split into several categories. The most obvious is hardware.

How much is the deployment of this prototype going to cost? When deployed, what are the ongoing costs incurred going to be? This often takes a bit of educated modelling; data transfer fees, for example, are heavily dependent on both deployment configuration and load on the system. Other questions include whether you need a highly available deployment, redundancy, etc. This will naturally cost more than a smaller, less resilient deployment. If it’s a prototype, you could easily argue that HA isn’t a mandatory requirement.

What about the human costs? Who is maintaining the software? Ensuring it’s running and fixing issues with it if it does fall over. A support person or people will need to be on hand to fix these things, and that doesn’t come for free, so is there a budget set aside for that?

Software is not just your software development but also elements of software that are required to keep the team and processes flowing. Do you use Github? If you use the free version, are the limitations acceptable for using it for deployment, builds, etc., in GitHub Actions? Likewise, is it used for bug and issue tracking? Will this be enough, or do you need something else like Jira? Trello? Ensure the monthly subscription costs are baked into the budget if they are specific to this project.

Software

This is another one of those questions that we discuss in depth with our customers. What are they planning to deploy? Does it exist? If it exists, how is it currently set up, deployed, and tested? We need to ensure that the code being deployed is in a fit state for hosting, but also, if it doesn’t exist, what do we need to do to get it to a point where it can be hosted?

The other important reason we ask about software is that it often helps us formulate a hosting topology for the software moving to the Cloud or other infrastructure. Do we leverage Cloud managed services? Or do we spin up containers or VMs to run the software on? This all impacts how the prototype is built, how it is supported, and its ability to scale further down the road.

In house Talent

This affects how we configure the deployment and how the handover and cross-training occur. We help every step of the way, but we want our clients to take ownership and feel empowered by our presence.

These are just a few ideas of questions we ask when engaging our customers for the first time. We want to ensure we’re a good fit and that everyone understands the “asks” from both sides. We want to ensure we build an infrastructure service that allows companies to progress from prototype to MVP to production naturally. However, we also want to ensure our customers know what to expect from us. Creating an environment where the communication channels are open, expectations are set, and prototypes and MVPs are given the best chance to succeed.