Choosing the Right Platform for Your New AppWalking through the process of selecting the platform that is right for youAllen HeltonBlockedUnblockFollowFollowingMay 17We live in a world overflowing with possibilities.
We are inundated with potential options for everything we want to do.
This includes development platforms when building a new application.
It doesn’t matter if you’re building a mobile, desktop, or web application, you are provided with numerous different frameworks and technologies on which to write your code.
Perhaps one of the most important decisions you can make when developing your app is the platform you are going to build on.
Once you choose it and begin development, you’re stuck with it.
Sure, you can refactor the solution after you implement it, but it’s simply that: a refactor.
Changing the platform would require a rebuild.
Therefore, we need to take all of our options into account to make sure we choose the right platform the first time.
Have a Clear VisionSoftware development is a process.
Deciding on the platform has its place in the process, but you must first decide what it is you’re going to build.
Make sure you understand the problem you are facing and have an idea of how you want to solve it.
A helpful technique I learned from some folks at AWS to coax out important details and design decisions is a product design meeting called a Working Backwards session.
A Working Backwards session will make sure stakeholders from different parts of your organization are aligned with the vision and elicits feedback necessary to build a well-rounded product idea.
Your vision doesn’t have to be complete before you move on to the next step, but it does have to be accepted by the stakeholders.
Don’t spend time getting ahead if you haven’t received approval on your idea.
Making your intentions clear is the most important part of your product vision.
Decide on the Right ArchitectureNow that you have a clear vision of the problem you are trying to solve and how you want to solve it, determining the high-level architecture is your next step.
What patterns best fit the problem?.At what scale do you need the app to perform?.Do you want an on-prem installable app or an app in the cloud?.Do you want to take advantage of managed services or write your own?These are just a few of the many questions that drive the proposed architecture of a new product.
Don’t get caught up trying to get too specific.
Your goal is to decide on architectural patterns.
The programming languages you are going to use don’t matter at this point.
Remember, these are your steps to choose the platform you are going to build on.
Explore Your OptionsWith so many options out there for platforms, how do you decide which to build on?.It is important to consider the estimated time to market and the size of the team building your app.
Are you working on a tight deadline?.Do you need something that is rock solid on day 1?.Here are some options I’ve run across when building new applications from the ground up.
Build it all yourself — There are times when building an installable desktop app fits the need the best.
You start from a blank slate and piece together your application.
This offers tremendous flexibility, but it can be time-consuming.
Also, since everything is hand-written, you have the highest risk factor due to human error.
Assemble vs Build — Thousands of companies exist today that specialize in one piece of an application, such as notifications, event busses, or document management.
One platform ideation is to utilize as many of their services as possible so that you don’t have to write it all yourself.
By assembling these services, you’ll end up with a quicker time to market and the responsibility of each service lies on the provider, meaning your team is not spending their time supporting, but rather innovating.
Platform as a Service (PaaS) — Rather than assembling services from different vendors together to make your super app, you can take advantage of a PaaS company.
These companies have already done the heavy lifting of orchestration, compliance, and hosting.
You simply build your application on top of their platform and utilize their builders.
Companies like Twilio offer a rich set of features that make it entirely possible to build your entire app from their dashboard, spending a fraction of the time it would take to build it all yourself.
Low Code — A flavor of PaaS, low code platforms have also taken the complexity out of code writing and given you a fast track to application building.
Low code tends to revolve around the idea of a visual designer to map out everything from your data entities to your user interface.
When it’s time to compile, your visuals are generated into code behind the scenes and auto-deployed into a CI/CD pipeline.
If you’re looking to get your application out as fast as possible, consider a vendor like Outsystems to get you started.
Prove It OutSelect a few of the options at your disposal and try to prove out your architecture with a Rapid Prototype.
A Rapid Prototype is a high fidelity, functional proof of concept designed and developed in a single sprint.
It is intended to provide a rich user experience and portray an idea to solicit feedback.
Building a Rapid Prototype in each potential platform will help you directly compare the platforms against each other.
It will also give you a chance to learn about the architecture as you implement it multiple times.
Each iteration should lead to a clearer understanding of how it works and the best practices around the patterns you chose.
To build a consistent Rapid Prototype, you need to decide on the proof of concept criteria that are most important to you and your stakeholders.
Focus on your gamechanger.
What can you build that will portray your idea the best?.In the past, I have worked on teams who made light product specification documents and built the prototype as close to the spec as possible.
This guaranteed the team was building the same product for each platform being assessed.
An important part to remember when proving out the platforms is to give each of them an equal chance.
If you’re like many software engineers today, you might turn your nose up at a low code platform because it “isn’t coding.
” Even if you don’t fully agree with the premise, give it a fair chance and you might be surprised with the results.
Remember, your job is to build an application, not just to write code.
Get Objective with the ResultsSeeing the software generated by each platform side by side is one thing, but coming up with a definitive winner can be a challenge.
So many factors come into play when deciding on the platform, from cost to developer experience to supportability, the software you see in front of you is just the tip of the iceberg.
Come up with a grading scheme to be objective and get a decisive answer.
When comparing platforms, I break my assessment into 8 categories:Developer Experience — How is it for the developers?.Can they get up to speed quickly?.Is it easy to build a new feature or read someone else’s code?Operations — How does the platform integrate with things like CI/CD, external services, or other managed services?Architecture — Does the platform allow me to build the architecture I want?.If not, what is the alternative?.Of my core pieces of functionality, what is easy to implement?. More details