Tools Are Easy. Pipelines Are Hard. 15 Years Building An Art Pipeline At Bossa Games

Introduction

The history of Bossa’s art pipeline is also, in many ways, my own path into becoming a Tech Artist and programmer.

Over the past 15 years the tools, languages, and systems have changed repeatedly. What hasn’t changed is the underlying question:

“How do we keep artists doing what they are best at, by removing unnecessary friction?”

This post isn’t a blueprint or a perfect solution. It’s a record of how a pipeline evolved over time through real production needs, small frustrations, and gradual iteration.

I’ll walk through that evolution, but more importantly, I’ll focus on the principles that emerged along the way, why certain decisions worked, where things didn’t hold up in practice, and what actually helped the team day-to-day.

Pipelines aren’t just technical systems. They sit somewhere between tools, workflows, and people. Understanding how those pieces interact is where most of the value comes from.

I’ll finish by reflecting on where we are now, and how changes in team size and tooling -particularly AI – are starting to shift what pipeline work looks like going forward.

Core Principles

These principles weren’t defined upfront. They emerged over time through iteration, mistakes, and observing how the team actually worked.

• Make the correct workflow the easiest workflow
  If workarounds are faster, people will use them.

• Reduce micro-frictions
  Small, repeated actions add up quickly and have a disproportionate impact on productivity.

• Automate the tedious parts, not the thinking parts
  Remove repetitive work, but keep ownership and decision-making with the artist.

• Design for real human behaviour
  Artists will work around problems, avoid asking for help, and stick to familiar workflows. The pipeline needs to account for that.

• Prefer robust systems over fragile workflows
  Avoid solutions that rely on perfect user behaviour or break easily when assumptions are broken.

• Make assets traceable
  Every asset should be easy to track back to its source without relying on “just remembering”.

• Assume iteration is inevitable
  Workflows, assets, rigs, and requirements will change. Systems should support change rather than resist it.

• Build a capable, not dependent, team
  Tools should help artists understand the pipeline, not hide it completely.

Timeline

The pipeline wasn’t built in one go. It evolved incrementally over time, each step solving immediate problems and exposing new ones.

• Customised existing MD5 export MEL script. Basic “rig removal”, minimal validation
• Exporter script grows, UI becomes cluttered, MEL starts to struggle
• Start of the Python-based pipeline
• Introduction of the pipeline shelf and toolbox
• Addition of analytics
• Git auto-updating
• Pipeline rigs and more advanced animation tooling
• The pipeline installer
• Unity C# integration

Current Pipeline Functionality & Features

Pipeline Manager & Projects

The core of the current pipeline is the pipeline manager and its project definitions.

Maya has its own project system, but it relies on artists manually setting it via File > Set Project. In practice, this is easy to forget and rarely enforced.

The pipeline manager addresses this by creating a ScriptJob on startup, which runs whenever a scene is opened. It checks the file path, and if it falls within a known project, automatically sets the correct Maya project.

This ensures relative paths are maintained and prevents scenes from being saved with absolute paths to assets.

It’s a small change, but it removes a common source of broken scenes and eliminates the need for relinking assets after the fact.

Having a project definition also enables other parts of the pipeline. Export paths can be automated, and project-specific configuration can be applied consistently without relying on manual setup.

One-click exports

One-click exports weren’t the starting point of the pipeline (that was animation tooling), but they quickly became one of the most valuable improvements.

By observing how artists – and myself – actually worked, it became clear that a significant amount of time each day was spent exporting and re-exporting fbx files. The more organised artists would find some shortcuts in the process, but a typical export often looked something like;

• File
• Export
• Select the output file in the file window
• Click Export
• Copy the exported file into source control

There are a lot of assumptions in that process, and each step adds a small amount of thinking time and room for error.

We also try to maintain a separate artist working folder (Dropbox in our case) as a source of truth which allows non-engine contributors (art direction, marketing, external partners) to access files too. This adds a small amount of overhead to the export process.

Even in a “typical” case, exporting is at least 5-6 interactions. Realistically, it takes around 15-30 seconds. If you repeat that 10 times, that’s 2.5-5 minutes.

Across a team, this becomes significant. 5-10 minutes per day per artist is a reasonable estimate. With 6 artists, that’s close to an hour per day spent on something entirely repeatable.

The one-click export system reduces this to a single action, with three main flavours:

• Whole Scene – export the entirety of the Maya scene, to an fbx file of the same name
• Selection (single file) – export current selection as one fbx
• Selection (multiple files) – export each selected object as its own fbx

There are additional details (overridable names, ignored groups), but the core idea is simple and covers most common use cases. Selection as individual files is a big time-saver for bulk operations.

This one-click exporting uses the pipeline’s project definition, to output the exported file into a mirror of the file system in art source, into the game repository.

e.g. Dropbox\My_Project\Environment\HouseA\Scenes\HouseA.ma would map to Git\My_Project\Assets\Art\Environment\HouseA\HouseA.fbx

“Do you check in assets to Git as well?”

Short answer: no.

Whilst the art pipeline does have Git functionality, there are some issues with automating asset commits:

1. When using text-based meta data, Unity creates .meta files for every asset inside of the Unity project. When committing new assets, if this is done automatically, Unity would not import the file and not generate the .meta file. This leads to GUIDs issues where some assets can become unlinked later. This can result in lost work and time spent debugging missing assets.
2. Artists don’t build familiarity with source control. Git is called “Git” for a reason – it’s not always the nicest to work with – but with repetition, coaching, and understanding you can build an art team that is resilient and capable of using it. But that only happens if you encourage it. Arguably, if it were possible to totally automate this process so the artist would never see a git client then it would be worth it. In practice, some interaction is always required, so it’s better to embrace it.
3. More importantly, it doesn’t encourage artists to check their work in Unity first. Blind commits – marking work as “done” without seeing it in situ – lead to some avoidable issues. This creates another time sink: if artists don’t fully own and check their work, problems are passed downstream. Programmers then spend time diagnosing issues, broken assets and ownership – all of which could have been caught earlier.

While it’s technically possible to automate commits, I chose not to. Pipelines should reduce friction, but not remove understanding. Artists benefit from understanding how and when their work is committed.

Pipeline rigs

The “Pipeline rigs” concept is one of the more involved parts of the pipeline, but it is also more niche.

The core idea is that rigs are defined as JSON data within the project, allowing the pipeline to have a more explicit understanding of the rigging and animation process. This originated as simple “rig removal and bake” functionality.

This allows artists to isolate specific rigs and export them in different ways:

• Geometry + a single frame timeline for avatar creation in Unity
• Skeleton-only animation exports, using Unity’s @animation_name naming convention

An important extension of this is the “Master Rig” concept, alongside versioned rigs. At Bossa, animation is always done on referenced rigs rather than directly on the rig file. This allows continued rig iteration underneath existing animation (as long as changes are not too disruptive).

This approach reflects a core assumption: iteration is inevitable. The rig/animation referencing model is not new, but it is fundamental to keeping iteration manageable.

An early mistake with this approach was relying on versioned rig references directly. Every time the rig version changed, animators had to manually update references across all animation files.

The “Master Rig” concept resolves this. A stable rig file (e.g. female_rig.ma) acts as the reference target, while versioned rigs live alongside it in a /rig_versions directory (female_rig_01, etc.).

This allows riggers to iterate on versions while maintaining a stable reference point. Animators can reference a rig through the pipeline tools and always receive the latest approved version, without needing to manually update references. Both sides can work in parallel without drifting out of sync.

The project rigs system is more complex than basic export tooling, and maintaining it requires more discipline. However, it still follows the same principle: remove repetitive, mechanical work while leaving creative control intact.

It also enables more advanced features (retargeting, facial rig helpers, animation layer tools), but the primary value remains simple: improving the speed and reliability of getting rigs and animation into the engine for iteration.

Unity Metadata

A principle that became more important over time was that assets should be traceable.

In simple cases this doesn’t feel especially urgent. If the team is small, the project is fresh in everyone’s mind, and the person who exported the asset is sat a few desks away, then finding the source of an fbx is not too painful. But projects grow, people change roles, files move, and memory is unreliable. Eventually someone is looking at an asset in Unity and asking a basic but important question; where did this come from?

An obvious solution is some kind of metadata file (some folks call it a side-car). Export tree_a.fbx, then generate tree_a.json next to it containing the Maya source scene, export timestamp, perhaps the user name, maybe even some project-specific data. This can work, but separate metadata is fragile, and it clutters file systems.

The fragility comes from the requirement that the metadata must always stay alongside the asset, something that is easily broken when files are moved or reorganised.

The more robust solution was to embed metadata into the exported fbx itself. This allowed us to include useful information such as;

• Source Maya scene path
• Artist name
• Export timestamp

This sounds like a small convenience feature, but in practice it solves a very real production problem. If someone in Unity found an issue with an asset, they no longer had to ask around or guess where it came from. They could use a Unity tool to inspect the imported asset and jump back to the originating Maya file.

That shortened feedback loops considerably. It also reduced one of the more annoying classes of production confusion, where an asset exists, works, but no one is quite sure who last touched it or where its authoritative source actually lives.

This is a good example of preferring robust systems over fragile workflows.

Pipeline Errors, Analytics, and Adoption

A common trait I’ve observed is that artists often tolerate repetitive work, build workarounds, and avoid raising issues until they become blockers.

We’ve already worked hard to address repetitive work, but efficient workflows are useless if artists don’t use them, or quietly work around issues. It’s not that artists want to cause problems, in most cases it’s the opposite.

Most artists don’t want to be a burden or look “stupid”, so they avoid asking for help. Another factor is resistance to relearning workflows. Part of the solution is “hearts and minds”, supporting and encouraging the team. But you can make your job easier by solving real, everyday problems, and building tools that are simple and robust rather than complex and fragile.

None of this changes the fact that artists can still be resistant to change, and that tools will occasionally break.

This is where error handling, analytics, and adoption strategies become important.

Errors

One of Maya’s weaknesses is how it surfaces errors to the user. By default it tints its single-line console view red when an error occurs. The intent is that the user notices and opens the console to investigate.

In practice, errors often get screenshotted and passed around, sometimes as a full-screen image for a single line of text.

To address this, the Art Pipeline uses a set of wrapper functions around Maya’s confirmDialog , to deliver concise user-facing error messages when the pipeline fails, or the input is invalid.

The goal is to be clear, but sparing. Too many popups and they get ignored, bringing you back to the original problem.

A simple example: an artist tries to export selection to a fbx, but nothing is selected. It sounds obvious, but a clear “Please select what you wish to export” is useful here.

After a successful export, a confirmation like “File {filename} has exported successfully” helps reinforce that the action has completed. A silent success can be as problematic as a silent failure.

These confirmation wrappers still log to the console, which remains useful for deeper debugging or escalation.

Errors should be visible, understandable, and actionable – not something the user has to interpret.

Analytics

Improving how errors are presented helps, but it doesn’t solve everything. Unexpected issues still occur, whether in the pipeline itself or in Maya more broadly. Tech Artists often end up acting as informal IT support, so relying on users to accurately report problems is rarely enough.

Relatively early in the pipeline’s Python phase, I introduced a pipeline-analytics module to log tool usage and capture errors.

Capturing both pipeline-specific exceptions and Maya errors meant I could see common issues across the team, and often already had the relevant error information before an artist reported it. This significantly reduced the amount of back-and-forth needed to diagnose problems.

Tool usage analytics also made it possible to reconstruct “user journeys”. Instead of asking what happened, I could see sequences like: this tool was used, then another, followed by an error. This additional context was particularly valuable as the team grew, where manually reconstructing issues became more time-consuming.

Pipelines shouldn’t rely on users to explain problems. Where possible, they should surface them automatically.

Adoption

I initially thought analytics would help drive adoption, and to an extent they did. Being able to see where tools were failing or causing friction was useful, but it wasn’t the core problem.

Adoption came down to something simpler: tools needed to provide more value than overhead. The correct workflow needed to be the easiest one.

One-click exporting and project management reduced enough friction that artists could iterate faster with fewer mistakes. A significant amount of repetitive and fragile work simply disappeared.

On one occasion, an artist leaving the company asked if they could continue using the pipeline in their next role, which suggested we’d gotten something right.

This isn’t to say everything worked flawlessly. As functionality became more complex – particularly around rigs, animation, and character customisation – more issues emerged, along with the need to enforce certain behaviours and standards.

Adoption isn’t something you enforce, it’s something you earn.

Help

Early in my career, I was spending a significant amount of time debugging issues for artists. I enjoyed helping, but over time it became clear that many of the same problems were occurring repeatedly.

This is where documentation became necessary.

Documentation only works if it is accessible and usable. In practice, that means:

• Keep it short
• Keep it close to the tools
• Make it easy to find

Long-form explanations may be useful when writing, but most users only need the condensed version. If documentation is too long or too far removed from the workflow, it won’t be used.

In Maya, this meant attaching help directly to tools via right-click shelf menus. I built a small helper module that maps tools to documentation pages, allowing functions like:

pipeline-help.launch-help("export-selection")

This keeps help within reach, both for users and for maintaining the documentation itself.

However, documentation alone is not enough. Without reinforcement, people will default to asking questions instead of using it.

One of the more consistent habits I had to build was redirecting questions back to documentation:

“Have you checked the docs?”

The goal isn’t to avoid helping, but to avoid answering the same questions repeatedly. Time is better spent solving new problems, not re-answering documented ones.

This requires some balance. Being overly rigid can hurt collaboration, but being too available turns you into the team’s search engine.

Over time, with consistent reinforcement and good documentation, the team begins to rely on the system instead of working around it.

You don’t want to become the team’s search engine.

Auto Update & the Installer

This aspect of the pipeline is relatively recent, and something tackle earlier in future. There’s a common theme throughout this post: keeping things accessible and simple. Tool setup, however, is rarely simple.

Tooling that is hard to install or keep up to date will not be used consistently.

When the pipeline was a single mel script, it was relatively simple to share and direct, but in its current form, the pipeline has 10+ modules, dependent packages, and various supporting scripts. Combine that with one-time setup, and per-project configuration, you quickly enter high-friction territory.

Already sounding like a problem? Now add the need to update tools across the team, and the need to debug issues caused by people being on different versions. This combination is enough to sabotage consistent pipeline usage across a team.

If you’re onboarding new artists or rapidly rolling out changes deadline pressure, it’s very easy to reach a “just work around it” moment, which is often the beginning of the end for a tool.

Setup friction kills adoption, just as quickly as bad tools do.

Auto Update

Auto-update was the first of these two features I tackled, mainly because keeping everyone up-to-date was more time-consuming then one-time setup.

Initially, the pipeline lived inside Dropbox, alongside out source files. This worked well enough for a time, but this quickly broke down when iteration and collaboration on the tools increased.

Nothing endears you to your animators more then their rig export tool breaking unexpectedly, or when you and another tech artist are trying to edit the same file, and Dropbox inevitably botches conflict resolution.

Given that we were already using Git for game repositories, moving the art tools there made sense. Installing the pipeline became “clone this repo, and configure it”, and then updating became as “simple” as git pull.

But how do artists know when to pull? With the art pipeline we had the notion of a version number so I could see who wasn’t up to date, but constantly reminding people to update is not scalable.

Adding an auto-update module addressed this directly. On Maya startup it queries the pipeline repository, and if the user was on the main branch and not on the latest commit, it would prompt for an update. If the working copy git has local changes, it prompts the user to clear them before updating.

This does introduce the new requirement: Git must be available on the system path so it can be invoked directly, rather than through a client like “Git Extensions” or “Source Tree. But one step at a time.

Tools consistency is critical, debugging becomes much harder when everyone is running different versions.

The Installer

The installer has almost closed the loop on pipeline scalability, particularly when onboarding multiple artists in a short space of time.

To understand the need for an installer, here’s what the current pipeline requires;

• Git for windows, installed and accessible on the system path – Required for production code anyway
• The repository cloned – (git clone)
• The Maya environment file configured – sample env copied, with two user-required paths to be entered
• PyMel installed for the appropriate Maya version (if not already present)
• Project manager data and sample project copied
• Migration from previous tools installations

None of this is particularly time-consuming for a Tech Artist, or even an artist following documentation, but these are solved problems which can largely be automated. The goal was to remove as many variables as possible, and minimise required user input. This consistency has significantly reduced onboarding time and troubleshooting effort.

The “nearly” comes from the remaining need to duplicate and modify json files to create new projects definitions. It’s straight forward, but not a frequent-enough to justify further tooling, especially given that tooling effort comes directly off of project time.

Not every problem is worth automating, but automating the right ones is key.

Where Are We Now, and What’s Next?

We’ve now caught up with the present, and what stands out most is how iterative this journey has been. There was no grand design, just a sequence of decisions based on immediate and near-term needs, evolving continuously over the past 15 years.

We’re now at a significant inflection point. The games industry is changing rapidly on two fronts: mass industry layoffs with smaller teams becoming the normal, and the rise of generative AI/large language models.

A Smaller Art Team in a Smaller Industry

Bossa has changed significantly over the past 15 years, starting from fewer than 10 people, and now returning closer to where we began. Throughout that time, the art team has grown and contracted, but has remained one of the more stable teams in the company.

Sadly we find ourselves in a position whereby we have a lot fewer artists then we once had, which raises some important questions about what comes next for the pipeline.

When the team is stable and of a moderate size, you start to encounter issues of scale. It only takes a couple of artists hitting blockers on the same day for a Tech Artist to lose a morning to troubleshooting. As a team grows, the likelihood of this increases.

The nature of those blockers also changes, they may come from feature requests as much as from issues in existing process. You can only mitigate part of that with intelligent tooling, but you still do what you can.

Over time, as both the team and the tools mature, troubleshooting time caused by controllable issues decreases. The team had become proficient with the tools and more capable of debugging issues independenly.

In this more stable and somewhat ideal scenario, myself and Bossa’s other Technical Artist were able to focus more on game features, with less time is spent debugging. The need to rely on analytics to identify concerns dropped significantly for example. It’s not that all problems were solved, but more energy could be spent on the games themselves.

So what do smaller teams do to this equation?

At first, you might expect problems of scale to largely disappear, and if project scope reduces alongside headcount, that would be a reasonable expectation. In practice, this isn’t always the case. Projects still hit phases which require rapid scaling. This can take the form of contractors, co-development, or outsourcing.

Bringing in additional artists – even temporarily – requires the pipeline to scale quickly with minimal setup friction. Outsourcing adds a different challenge: large-scale review and integration of external work.

Bossa’s pipeline now scales well when onboarding new artists, but large-scale asset review and automated external workflows have never been fully addressed at the tooling level, and remain largely manual.

My preference has always been to embed artists into the team and have them adopt our tools, as it maintains standards and consistency. It also allows for better collaboration and generally produces better outcomes.

That isn’t always possible, so building or integrating tools for these workflows may become necessary.

I don’t have a complete solution for this yet, but the shape of the problem is clear… These are the areas I would explore if it became necessary:

Early Submission Mechanism for Pre-vis / WIP Concepts & Renders

Before reviewing source assets, visual approval should have been received. Catch major issues early and reduce unnecessary manual review work where possible.

Ideally, an outsource partner would already have a clear format for presenting pre-vis, concepts, or work-in-progress renders.

Submission Mechanism for Asset Review

After initial approval, there needs to be a reliable way for partners to deliver source files.

If file size becomes a practical concern the delivery method needs to be robust. Dropbox, Google Drive, WeTransfer, or even a dedicated FTP server can all work, depending on scale and reliability requirements.

Early Validation

Outsource deliveries often fail to match the expected standard first time. That means the burden is on us to define, communicate, and enforce standards clearly.

That can include:

• file naming
• folder structure
• scene layout

We should assume we’ll need to iterate on these assets ourselves. If files arrive messy, bloated, or disorganised, we pay the cost twice: once when we receive them, and again when we need to modify them later.

The ideal here is an automated validation that creates a report for the reviewer, allowing an opportunity to push back before detailed review begins.

Review Mechanism & Feedback

The right review process depends on scale. If a delivery contains a couple of assets, opening the source file in Maya is enough. At larger scales, the process benefits from more structure.

The first aspect of review is keeping feedback as close to the problem as possible. If you can highlight the specific patch of geometry, attach a comment, or provide a quick paint-over, that is ideal. Sometimes that can be as simple as taking a screenshot and dropping it into a shared document.

The second is seeing the asset in context. That is where the look-dev scene becomes important. Is the scale correct? Are the textures the right resolution? Does the asset fit the intended art style once placed in-engine?

Maya makes sense for geometry review, and Unity makes sense for final fit. The tooling question is how to support that handoff cleanly.

Integration Mechanism

Once an asset is approved, it then needs to be adopted as our own.

The ideal is that the asset can be merged into the project structure and set up in the same way as internally produced assets.

The main things to watch for are:

• material generation
• collider creation
• avatar definition
• animation definition

Each of these can be handled in different ways, and once again the value of tooling depends heavily on scale.

The real question is whether it’s more efficient for a Tech Artist to spend time building or automating this, or for the team absorb the cost manually?

Tech Artists are often needed for more specialised work, which means any tool we build needs to save several times the effort it costs to create, and ideally remain useful across future projects.

At this scale, the same principle still applies: solve the problems that remove the most friction, and accept the ones that don’t.

Pipeline & Tools Writing vs AI Coding

We’re now in a very different tooling landscape from the one I started in.

When I first began writing tools, much of the effort was simply in getting over the initial barrier to entry. You needed enough programming knowledge to begin, enough perseverance to debug, and enough confidence to keep going when the first version was ugly, error-prone, or didn’t work at all.

For many artists or designers, that barrier alone was enough to prevent them from ever starting. One of the more interesting effects of AI-assisted coding is that it broadens who gets to build tools.

There are many talented technical artists who have never fully crossed into programming. They still understand where friction is, which processes are brittle, and what would genuinely help the team. In many cases, that insight is more important than raw implementation ability.

AI tools can help lower that barrier.

They make it easier to prototype ideas, explore APIs, and turn good instincts into working tools. That feels especially relevant in technical art, where the hardest part is often not writing the code, but understanding the workflow well enough to improve it.

Artists and Tech Artists are often strong in that space.

They are used to working with ambiguity, iterating towards solutions, and exploring problems through iteration rather than upfront design. That mindset translates well to early-stage tooling, where the question is less “can this be built?” and more “does this actually help?”

In that sense, AI may enable more of the right people to contribute to tools: people who already understand the work.

However, this comes with a trade-off.

Writing a tool is not the same as building a pipeline.

A tool can be generated from a prompt. A pipeline needs to fit into a team, survive edge cases, tolerate inconsistent user behaviour, be maintainable by others, and still make sense months later when the project has changed shape.

None of that is solved by generating code more quickly.

AI makes it easier to produce tools that technically work, but AI doesn’t understand how the tool fits into the workflow, and is no substitute for experience. It also makes it easier to accumulate code that no one fully understands or feels ownership over.

That risk is real, but it depends heavily on context.

A tech artist writing a small, isolated Python tool that saves the team time is very different from a production engineer shipping large-scale systems they don’t fully understand. Pipeline tools tend to sit outside core production systems, so failures are less catastrophic and easier to recover from.

As long as that scope is understood, and there is clear ownership, this kind of experimentation can be safe and valuable. Problems emerge when tools become critical without anyone fully understanding how they work, and how to fix them when something breaks.

The exact shape of AI in production is still uncertain.

Costs, access models, and capabilities are all changing quickly, and it’s not clear what will stabilise long-term. Some of today’s assumptions may not hold.

But regardless of how the tooling evolves, the underlying problem remains the same.

Pipelines still need to fit teams, handle real-world behaviour, and remain maintainable over time. Those challenges don’t disappear if the tools become more powerful – if anything, they become easier to get wrong.

My view on AI-assisted tools writing sits in the middle of two warring camps:

AI allows more workflow-aware people to contribute directly to tooling, which is often where the best ideas come from.

But it also makes it easier to accumulate technical debt. It doesn’t remove responsibility from the user – if anything it increases it.

It helps with implementation, it does not replace judgement, ownership, or an understanding of how people actually work.

And those are still the things that make pipelines succeed or fail.

Conclusion

The pipeline was not designed upfront in its final form. It was discovered over time through real production needs, repeated frustrations, team growth, mistakes, iteration, and changing constraints.

In that sense, the pipeline reflects the team it was built for as much as it reflects any technical decisions.

Some of the most valuable improvements were not especially glamorous. Automatically setting a Maya project, removing several steps from export workflows, surfacing errors clearly, embedding metadata, and simplifying setup.

Individually, none of these are transformative. Together, they refine the day-to-day experience of producing art.

That, more than anything, is what good pipeline work really is.

Good pipeline work is not about building complex systems, hiding difficult concepts, or automating everything. It’s about reducing unnecessary friction, supporting how people actually work, and building systems that hold up in real production.

The tools are easier to build now than they have ever been. Smaller teams, tighter budgets, and AI-assisted coding all change how we approach pipeline work, but they do not change the fundamentals.

Tools are easier to build than ever.

The tools are easier to build now than they have ever been. Smaller teams, tighter budgets, and AI-assisted coding all change how we approach pipeline work, but they do not change the fundamentals.

Tools are easier to build than ever.

Good pipelines – the ones that fit a team, survive real use, and continue to make sense over time – are still hard.