What a Pre-AI Project Taught Us About Building Better Systems

Lately, I’ve been thinking about how software work changes when AI becomes part of the everyday toolkit.

When tools evolve this fast, even well-established practices start feeling temporary. The questions don’t disappear — they multiply. What becomes easier? What stubbornly refuses to change? And what blind spots emerge when speed becomes the default?

To ground that thinking, I’ve been revisiting one project that still shapes how we work at ColoredCow. Not because it failed dramatically — but because it worked long enough to reveal something deeper.

If we were building it today, with AI in the loop, much of it would move faster. Interfaces would come together sooner. Workflows would feel complete earlier. The system would appear “done” far more quickly.

From the outside, it might even look more successful in its early life.

That project did work for a while — and later, it had to stop.

Which is exactly why I keep coming back to it. As we rethink how we build at ColoredCow with AI, this is one of the experiences I want to understand more clearly.

It left us with a question we still carry:
would AI have changed its fate — or simply helped us reach the same limits sooner?

And if we combine what that experience taught us with what AI now makes possible, how differently might we build next time?

Failure, reconsidered

The system we’re reflecting on here was deployed into the real world. Real users depended on it. Real expectations were attached to its outcomes.

Users were onboarded in the field.
The outcomes aligned with what they needed — and for a time, those expectations were being met.

The work was institutionally backed.
Multiple funders supported it.
The idea had passed scrutiny.
The intent was taken seriously.

This wasn’t a speculative bet.
It was a system that had earned its place.

And yet, it didn’t continue.

When that happens, the language around a system shifts.

In review meetings, funding conversations, and retrospectives, complex trajectories get compressed. What was once a living system becomes a summary. A conclusion. A sentence that allows everyone to move forward.

We reach for verdicts:
success or failure, strong execution or flawed judgment.

That instinct isn’t careless.
It’s efficient.

Organizations need closure. They need narratives that travel. They need ways to account for outcomes without reopening every assumption.

But compression hides something.

In complex systems, outcomes rarely map cleanly to intent or competence. They emerge from the interaction between a system and the environment it must navigate over time.

Seen this way, failure isn’t an answer to what went wrong.
It’s a signal about a broader category of forces that surround a system — conditions like ownership, continuity, legitimacy, and endurance.

That project didn’t give us a final list. It pointed us toward the kinds of questions we hadn’t fully designed for — questions we’re still learning to surface earlier, especially as the tools around us evolve.

This distinction feels harder to ignore now.

With AI in the loop, it has become easier to reach early completeness. Systems can appear finished sooner. Confidence accumulates faster. Judgments get made earlier in a system’s life.

Which makes it even more important to notice what those judgments leave out.

AI can help us build faster, explore more possibilities, and surface patterns earlier. It changes what becomes visible, and when.

At the same time, there remains a broader category of forces that surround any system — conditions of ownership, continuity, legitimacy, endurance. How AI reshapes those forces is something we’re still learning to understand.

That clarity still has to be designed for — deliberately, and often before it feels necessary.

What early momentum makes easy to overlook

AI amplifies early signals.

It allows teams to move quickly from idea to execution. It reduces friction in building. It can make systems feel coherent earlier in their lifecycle.

That acceleration is powerful.

But it also changes how early momentum feels.

When a system is moving forward — especially quickly — a lot stays invisible.

Gaps get filled manually.
Exceptions feel reasonable.
People compensate for what the system doesn’t yet handle well.

Momentum absorbs friction.

As long as progress continues, the system appears more stable than it truly is. Early momentum creates confidence — not because risks are gone, but because they haven’t yet been tested under different conditions.

At certain moments — when growth stabilizes, attention shifts, or the system becomes routine — a different category of questions begins to surface.

Not because something is failing, but because the system is entering a new phase.

Questions like:

When usage stabilizes rather than grows, what sustains the system’s relevance?

Which assumptions were supported by early enthusiasm — and how do they hold up as that enthusiasm normalizes?

What dependencies, once flexible, are becoming structural?

And as roles evolve or attention redistributes, how intentionally has continuity been designed?

These aren’t signals of collapse.
They’re signals of transition.

AI doesn’t eliminate these transitions. If anything, faster execution can bring systems to these thresholds sooner.

Slowdown changes how visible they become.

When momentum shifts — even slightly — what once felt hypothetical starts to feel operational.

In that sense, early momentum doesn’t eliminate these questions.
It often shifts when they feel important enough to examine.

When nothing breaks, but everything shifts

There was no dramatic collapse.

No single outage.
No irreversible technical failure.
No clear moment when something visibly broke.

From the outside, the system continued functioning.

What changed was harder to point to.

Attention redistributed.
Energy reorganized.
Priorities evolved.

None of these shifts were dramatic on their own. They were gradual — almost administrative. The kind of changes that feel reasonable in isolation.

Over time, the surrounding conditions began to look different.

Not because someone made a wrong decision — but because the environment the system depended on was subtly rearranging itself.

Questions of ownership felt less concentrated.
Institutional pull felt less explicit.
Incentives that once aligned began to move in slightly different directions.

None of this announced itself as failure.

It simply changed what the system was being asked to sustain.

AI doesn’t automatically prevent these kinds of shifts. Faster execution and better tooling can strengthen what is built — but the surrounding conditions of attention, alignment, and responsibility still evolve on their own timelines.

AI may help surface some of these shifts earlier — through signals, usage patterns, emerging friction. But noticing a shift is different from designing for endurance.

That remains a human responsibility.

Without surrounding conditions that continue to support it, even a well-built system can become fragile — not suddenly, but gradually. It keeps working, right up until its context no longer reinforces it.

That fragility isn’t a moral judgment.
It’s what happens when systems and environments evolve at different speeds.

What staying with a system teaches you

Working on a system that doesn’t continue indefinitely teaches distinctions that early momentum alone doesn’t always reveal.

Not because early progress is misleading — but because different phases surface different kinds of truths.

While a system is expanding, attention is oriented toward possibility. The dominant questions are about capability and improvement.

As conditions evolve — growth stabilizes, environments mature, priorities shift — another layer of questions begins to matter.

Adoption isn’t the same as long-term commitment.
Usefulness doesn’t automatically translate into institutional legitimacy.
Technical correctness doesn’t guarantee structural resilience.
Growth paths don’t necessarily clarify how something should endure.

These are not failures.

They are transitions in what the system is being asked to carry.

A system’s quality isn’t fully visible while it is scaling.
Different aspects of its quality become visible as its context changes.

Sometimes that shift happens as enthusiasm normalizes.
Sometimes when ownership evolves.
Sometimes when attention redistributes.

Not because energy disappears — but because it changes shape.

If a system can adapt to those shifts, it strengthens.
If it was never designed with those shifts in mind, fragility becomes easier to see.

The habit we’re trying to unlearn

There’s a temptation to move past these moments quickly.

Archive the repository.
Summarize the outcome as “it didn’t work out.”
Extract a few lessons and move on.

In a time when AI makes rebuilding faster than ever, that temptation grows stronger. When iteration is cheaper, reflection can feel slower than progress.

But speed without understanding compounds confusion.

Systems that don’t continue often leave behind deeper insight than systems that expand without interruption.

Not every product is meant to persist indefinitely.
But every serious system has something to teach — especially when we’re building in a time where starting again is easier than ever.

If AI lowers the cost of building, it raises the value of learning.

A quieter conclusion

The most valuable outcome of a system isn’t always continuity.

Sometimes, it’s clarity.

Clarity about what a system was actually carrying.
Clarity about which forces shaped its trajectory.
Clarity about what we would design differently next time.

In a moment where tools are evolving rapidly, that clarity becomes an advantage.

Because teams that combine hard-earned experience with new capability don’t just build faster.

They build with better questions.

And those questions — more than any tool — shape what endures.