Who it’s for

SnipFlow suits any technical team that uses code versioning, from one person on a side project to a long-running cross-disciplinary team working on a mission critical product.

Agencies and studios

The SnipFlow methodology developed over a long history working in service-oriented environments; building projects for clients. It’s often the case in agencies and studios that each project is started from scratch, often with a team including many freelancers working to tight deadlines.

SnipFlow was born from a desire to find a common workflow that would embrace the different technologies, approaches and team disciplines across all these projects, while allowing for some level of organisational coherence.

The result in these environments is that each project gets a best in class developer experience with CI/CD setup, all project stakeholders get easy access to project links to see progress, team leads have enough process in place to keep on top of code quality, and staff members are able to rationalise easily about old projects when they are revisited later.

Product teams

While product teams tend to spend some time on their workflows and automation pipelines in any case, I’ve been surprised how many have processes that are still very manual and cause friction in the team.

It’s also the case that most teams still start side projects, whether they’re for spikes or secondary tooling or similar, and in general the main project’s workflow isn’t easy to replicate to a small new project. This then leads to a higher maintenance overhead, or to the smaller projects having less transparency and a worse developer experience, which over time adds drag to the team.

By using one scalable process across all their work, product teams find it easier to see all the pieces of work they do through the same lens, applying the same level of quality control and decision-making to all their work, and being more efficient along the way.

Individuals and side projects

Small one-person projects tend to get thrown together quickly at the start. As a result, they end up wither having a poor developer experience (e.g. little to no automation), or they lean in to products like AWS Amplify or Vercel for the auto-deployment features, for example.

Along with similar decisionmaking around process (e.g. committing directly to the main branch without much thought), these projects often end up very hard to maintain or rationalise about, which only adds to the likelihood of them falling out of use.

Worst of all, if they take off these approaches usually don’t suit more people or better collaborative teamwork, and effort then needs to be put into process engineering and reworking the repo history. Using SnipFlow from the beginning helps keep even small projects healthy, without imposing a lot of extra bureaucracy.