Creating a Rapid MVP Framework, Part 1
Thoughts on building a strong foundation for new software projects.
At Portal, our focus is on building custom software. Our clients typically need to solve complex business problems and user experiences that aren't provided by out-of-the-box platforms. We work as partners to bring solutions to life that our clients can use, test, and iterate upon over time.
Over the last several years, Portal has developed a platform we call our "RMVP" (Rapid Minimal Viable Product) Framework. RMVP is a set of tools, documentation, and body of software we use as a launch pad when starting new custom web applications from scratch.
Why Do We Need a Framework?
RMVP helps our team accomplish three objectives:
- We can launch working software to the cloud on day 1 of development.
- We have a uniform process for engineering at the onset of the software development lifecycle.
- We build living documentation from our experience building new software for our clients.
Launching Working Software on Day 1 of Development
Using infrastructure-as-code and configuration-as-code, we're able to create minimal, effective continuous integration and delivery (CI/CD) pipelines to test and deploy software to the cloud as soon as development on a new application is started.
Our clients use a variety of source control platforms (GitHub, Azure DevOps, and GitLab) - so RMVP encompasses templates for GitHub Actions, Azure DevOps Pipelines, and GitLab CI/CD.
Our standard rapid-prototype CI/CD pipelines include processes for running Docker container builds, automated unit tests, pushing Docker images to private repositories in the cloud, and, optionally, deploying new container images to appropriate staging environments.
By launching each new Rapid MVP project with templates for CI/CD from the beginning, we ensure that we're able to view deployed software in environments that mimic production as soon as code is pushed to a remote repository. This enables us to interact with the software quickly, start exploratory testing, demo to the client.
One of the critical aspects of running a software agency that works on multiple projects at any given time is defining a shared process for how we write, test, review, and deploy code. RMVP provides a strong foundation for unit tests, running database migrations, code linting, and other practices that we've reached consensus on as a team that work well for new projects.
Having a shared set of practices and norms for how the most critical aspects of new software development works enables our team to work flexibly across multiple projects and makes the most of what we've learned as a team in the past.
By tracking RMVP documentation in version control, we can easily access, modify, and understand changes to our processes over time. Furthermore, by storing this documentation alongside the source code it references, developers can easily find and explore modules and patterns in a single place using their standard IDEs or editors.
New engineers who join the team are able to clone the repository and start exploring immediately, making onboarding to our engineering processes more transparent.
As we learn from each new project we build, we create a feedback loop for changes into RMVP, continuously improving it as we would any other project.
In this post, we explored why we decided to formalize our Rapid Minimal Viable Product Framework, illustrating the benefits this has provided for kicking off new software projects.
In articles to follow, we'll dig into the RMVP project in more detail, discussing the particular modules, playbooks, and stacks we can launch using this platform, as well as how we evaluate trade-offs when building out implementation details prior to kicking off a new project.