How we deliver at centerbit: Six phases every project goes through

If you've ever talked to us about a potential AI or automation project, you've probably asked at some point: "What does this actually look like in practice?" That's a fair question, because many vendors promise outcomes but stay quiet about what happens between the signed contract and a working production system. In our work with customers in the SME segment and smaller teams, a six-phase model has proven itself, and we want to share it openly here. Not as a marketing guarantee, but as a description of what we actually do, and where we have occasionally gotten it wrong.

Why a fixed phase model is more useful than open-ended consulting

The typical starting situation: a company has an idea, maybe a ChatGPT account, sometimes just a vague feeling that "AI should somehow help." Without structure, projects end up as either expensive pilots that never reach production, or quick tool recommendations that get abandoned after three months. Both variants burn money and trust.

A phase-based approach helps us figure out early whether a project makes economic sense, whether the data is in the right shape, and whether the expectations are realistic. It forces us and our customers to agree on goals, responsibilities, and kill criteria before the first line of code. In our experience, that upfront work has the biggest leverage on project success.

Phase 1: Analysis and use case definition

We start with no tool and an honest stocktake. In a free 30-minute initial call, we clarify whether a concrete need exists or whether the conversation is really about orientation. Once a real need becomes visible, we move into a deeper analysis phase: we look at the relevant processes, document data sources, integrations, and existing tools, identify bottlenecks, and quantify where an automated workflow would actually save time or money.

Important: we deliberately do not sell a solution in this phase. If it turns out that a classic script, a better Excel template, or simply a process change is the right answer, we say so openly. In our recent projects, a significant share of incoming requests do not need a dedicated AI component, but rather clean data flows and clear responsibilities.

Phase 2: Build and architecture

Once the use case is locked in, we move into solution design. Together with the customer, we decide which components to use: which language model, which database, which integrations, which review mechanisms. The architecture phase also produces the first concrete plan for the pilot: what gets built, what we deliberately leave out, which assumptions we want to test in the pilot.

In our projects, we lean heavily on existing building blocks from our own products at this stage. The Facio Agent handles the execution logic, Placet provides the review and approval surface, and where document logic is needed, Autype comes in. This is not a dogmatic choice; it simply reflects the fact that we run these building blocks in production ourselves and know their limits. For customers, that means shorter build times, fewer unknown risks, and an architecture that does not collapse at the first real failure.

Phase 3: Pilot and testing

Before anything goes into production, it goes through a pilot. For us, this is non-negotiable, even when customers grow impatient. In the pilot, the agent or workflow is fed with real data but is strictly separated from live operations. Staff give feedback, corrections, and improvement suggestions. We measure how often the agent is right, how often it is wrong, and how much time is actually saved.

The pilot is also where trust gets built. Customers see for the first time what AI can and cannot do in their specific context. Expectations get calibrated. In our projects with tax advisory firms, trades businesses, and logistics companies, a two- to six-week pilot has consistently delivered more insight than three months of theory.

Phase 4: Evaluation and adjustment

After the pilot, we do an honest evaluation. We compare actual results with the goals that were defined in phase 1. Where were we right, where were we off, what worked, what did not. We do not file this evaluation away; it is the basis for the next decision: do we move into production, do we adjust, or do we deliberately stop the project here.

Not every project becomes production. That is something we struggled with early on but is now firmly part of how we work. Better to close a pilot honestly than to operate a half-finished production system that helps no one.

Phase 5: Production deployment

Only when the pilot and evaluation convince us, the system goes into production. In this phase, the focus is stability, monitoring, and clear ownership. We set up monitoring, document runbooks, train users, and make sure the customer knows what happens when something breaks. Where sensitive data is involved, we review hosting, data residency, and audit trails so the system not only works but also meets compliance requirements.

For production deployments, we consistently use our Placet surface for approvals. This is not just a technical decision but a cultural one: staff should not blindly accept AI suggestions, but should be able to review and approve them deliberately. Human-in-the-loop is not a buzzword for us; it is a deliberate pause built into the workflow.

Phase 6: Long-term maintenance and operations

Many vendors end their engagement at go-live. For us, that is where the second half of the work begins. AI systems are not software you set up once and then run for ten years. Models change, APIs change, business processes change. Without continuous maintenance, even a great system turns into a liability within a few months.

That is why ongoing maintenance is a fixed part of what we deliver. We monitor performance, react to model updates, review security and compliance aspects, and improve the system based on new requirements. It is part of our operations and maintenance pillar, and the reason our customers are not left alone three months after launch. If a system is running in production, it deserves a partner who keeps caring for it when nothing is spectacularly new.

What we have learned from our projects so far

Looking honestly at our projects so far, we have mainly learned that phases do not run dogmatically. Sometimes phase 3 surfaces new findings that reopen parts of phase 1. Sometimes the pilot shows that the architecture from phase 2 needs adjustment. That is not failure, that is normal. What matters is that each phase is walked through deliberately and closed, even when adjustments are required.

Second lesson: pilot before production is not an extra, it is the prerequisite for everything after it. We have seen projects where this step was skipped, and in nearly every case the downstream damage was more expensive than an additional pilot month. Anyone who treats a pilot as a delay will learn the hard way why you cannot skip it.

Third lesson: maintenance is not an add-on, it is core. An AI system that is not maintained regularly slowly gets worse. That is reality, and anyone who hides this from customers damages trust in the entire industry over time.

What you can take away from this process

If you are considering whether an AI or automation project makes sense for your business, three things matter. First, start with the use case, not the tool. Second, plan a pilot phase even when it feels inconvenient. Third, think about maintenance early, before the system goes into production.

If you are unsure where to start, the simplest first step is a 30-minute introductory call. Together we will figure out whether your project fits this phase model, which phases carry the most leverage, and where you can realistically start. No obligation, no sales pressure, just an honest assessment of what actually makes sense.