Principal-led delivery that speeds CMS modernizations by reducing handoffs and accelerating technical decisions.
Get practical Sanity guides with working examples, schema templates, and time-saving prompts. Everything you need to build faster with Sanity CMS.
No spam. Unsubscribe anytime.
A digital platform project can involve strategy, user experience, content architecture, application development, integrations, infrastructure, security, migration, and ongoing operations.
Many companies assume that a larger delivery team will complete this work faster.
For focused platform engagements, the deciding factors are usually communication distance, senior involvement, decision speed, and the number of dependencies between workstreams.
A small senior team can move quickly because the people understanding the business problem remain directly involved in designing, building, and validating the system. Information travels through fewer layers. Architectural decisions reach implementation immediately. Technical constraints reach the client before they become expensive.
This delivery model works particularly well for B2B websites, CMS modernizations, marketplaces, partner portals, internal applications, and practical AI systems.
Every project has a decision path.
A business requirement enters the project. Someone interprets it. Someone translates it into a user experience. Someone defines the data model. Someone implements the feature. Someone tests it. Someone explains the result back to the client.
The length of this path affects delivery speed.
A larger team may include an account manager, strategist, project manager, business analyst, designer, solution architect, frontend developer, backend developer, infrastructure specialist, and quality assurance team.
This structure provides substantial capacity, though it also creates communication dependencies.
A requirement can pass through several interpretations before it reaches the developer. A technical constraint can travel back through the same chain before the client receives it. Each transfer introduces waiting time and the possibility of context loss.
A principal-led team shortens the path.
The person discussing the business problem can also define the architecture, supervise implementation, review the result, and explain the tradeoffs. Design and development decisions can happen together rather than moving through separate departments.
The resulting speed comes from reduced coordination overhead.
Digital platforms rarely consist of independent features.
A content model affects migration. Migration affects launch sequencing. User roles affect the database structure. The database structure affects APIs. Hosting affects backups, recovery, and cost. Caching affects performance, publishing, permissions, and content freshness.
One decision creates consequences across several layers.
A fragmented delivery model can assign each layer to a separate specialist. Every specialist may make a sound local decision while the complete system becomes inconsistent.
A senior full-system team sees the connections earlier.
For a recent multi-brand CMS architecture engagement, the work included:
These requirements could not be solved as separate tasks. Brand architecture affected permissions. Permissions affected editorial workflows. Product ownership affected the content model. The content model affected migration. Hosting affected media, deployment, and recovery.
The project moved efficiently because these decisions were handled as one connected system.
Many companies buy senior expertise during the sales process and receive a more junior delivery team after the contract is signed.
The senior people may join major meetings or review important milestones, while day-to-day interpretation and implementation move to others.
This can work well when the agency has strong internal systems and the project contains repeatable work. It becomes less effective when the engagement depends on continuous judgment.
Platform projects create decisions throughout delivery:
Direct access to the person making these decisions shortens the feedback cycle.
The client can raise a business concern and receive an answer that considers architecture, cost, implementation, and long-term operation in the same discussion.
A small team only works when it has sufficient breadth.
A narrow specialist may need several supporting roles to deliver a complete platform. A senior generalist with production experience can cover more of the delivery chain.
My own work spans:
Katharina contributes user experience, interface design, and visual systems.
This structure allows us to move from business requirements to a working implementation without recreating a department for every layer.
Specialists can still be added when the project genuinely requires them. The core team remains small, and additional expertise is introduced around a specific need.
AI-assisted development has increased the amount of implementation a small experienced team can complete.
Interfaces, APIs, data transformations, integrations, tests, infrastructure configuration, and documentation can be produced faster. The senior team can spend more time on architecture, business rules, validation, and production behaviour.
This changes the relationship between headcount and output.
A larger team still provides more human capacity, while a small senior team now has much more implementation leverage than it had several years ago.
During a recent financial-services marketplace prototype, a compact team covered:
AI accelerated implementation. Senior judgment defined how the pieces should work together.
The effective delivery capacity came from combining technical breadth, direct ownership, and modern tools.
Complex projects often develop ambiguous ownership.
The design team owns the interface. The development team owns the code. The infrastructure provider owns the environment. The client owns the requirements. The project manager owns the timeline.
When something fails between those boundaries, responsibility becomes difficult to identify.
Principal-led delivery creates a clearer accountability model.
One senior person remains responsible for understanding the requirement, defining the system, supervising implementation, and ensuring that the delivered platform works as intended.
Principal-led delivery gives the client one clear technical owner for the complete outcome, without removing the client's responsibility to participate in business decisions.
That accountability becomes valuable when the platform crosses several domains.
Large agencies provide capabilities that a small team cannot reproduce.
They can support many parallel workstreams. They can assign dedicated specialists to research, branding, accessibility, security, content production, native applications, enterprise integrations, testing, training, and international rollout.
They can also absorb personnel changes more easily and provide formal procurement, governance, and support structures.
The right delivery model depends on the programme.
| Project condition | Small senior team | Large agency |
|---|---|---|
| One focused platform or modernization programme | Strong fit | Can work, with more coordination |
| Direct access to technical decision-maker required | Strong fit | Depends on staffing model |
| Many simultaneous product workstreams | Limited capacity | Strong fit |
| Requirements likely to evolve during delivery | Fast direct iteration | Requires strong internal communication |
| Extensive brand research and campaign production | Additional specialists required | Strong fit |
| Complex system with a defined core scope | Strong fit | Strong fit |
| Global rollout across many regions at once | Limited without partners | Strong fit |
| Cost sensitivity and need for senior attention | Strong fit | Higher overhead likely |
| Large procurement and governance requirements | May require adaptation | Established processes |
| Ongoing high-volume support desk | Limited without support partner | Strong fit |
The choice should follow the delivery problem rather than a general preference for team size.
A larger organization carries more operational structure.
Revenue supports sales, account management, project management, leadership, offices, internal operations, and periods between projects. These costs are reflected in project pricing.
This overhead can create value. Project managers coordinate large programmes. Account teams maintain communication. Leadership provides governance. Specialist departments provide depth.
A focused engagement may not need the complete structure.
A small senior team can direct more of the project budget toward the people making decisions and producing the work. The client receives senior attention without funding as many internal layers.
The economic advantage is strongest when the scope is complex enough to require experience and focused enough to avoid a large delivery organization.
A small team can move quickly and still create operational risk without a controlled process.
Fast delivery requires:
Direct communication should reduce process overhead. It should preserve the safeguards required for production systems.
The goal is a lean process with strong controls.
Decision-makers should look beyond the number of people shown in a proposal.
The more useful questions concern ownership and capability.
The proposal should identify the person responsible for architecture, data, security, infrastructure, and major implementation tradeoffs.
Senior participation should continue beyond discovery and sales.
A short communication path supports faster clarification and reduces interpretation loss.
The team should cover the major layers required by the project. External specialists should have a defined role.
A small team should be honest about concurrent engagements, availability, and the work it can support simultaneously.
The team should explain migrations, testing, access control, deployment, backups, and production validation.
The client should know who remains accountable when a problem crosses design, data, application, and infrastructure boundaries.
A complex platform does not automatically require a large team.
It requires enough capability to understand the business, design the system, implement it safely, and operate it responsibly.
For focused digital platforms, a small senior team can often provide the right combination of speed, direct communication, technical breadth, and accountability.
The model succeeds when senior people remain hands-on, the scope is controlled, and the team understands the complete system.
A small senior team can build a focused enterprise-grade platform with a controlled scope. Large programmes involving many products, regions, integrations, and simultaneous workstreams require additional capacity.
Enterprise quality concerns security, reliability, governance, and operational discipline, not a specific team size.
Yes. Concentrating knowledge in a small team creates continuity risk.
This can be reduced through documentation, client ownership of code and infrastructure, automated deployment, clear operational procedures, and access for additional technical partners when required.
The core team should cover the central delivery path. Specialists can be introduced for defined areas such as penetration testing, legal compliance, native mobile development, advanced data science, or large-scale cloud operations.
The project remains efficient when specialist involvement is focused and coordinated by the core technical owner.
A small team generally carries less organizational overhead. Senior specialists may still charge higher rates because the client receives direct access to experienced people.
The relevant comparison is total project cost, delivery speed, rework, and the quality of the resulting system.
A large agency is appropriate when the programme requires many parallel teams, extensive creative production, global rollout, formal support operations, or broad specialist coverage.
It is also appropriate when procurement and governance requirements favour an established organization with substantial staffing capacity.
The delivery model should match the actual shape of the engagement.
A focused CMS modernization, marketplace, internal application, or AI-enabled workflow often benefits from a compact senior team with direct ownership from discovery through production.
A broad transformation programme may require the capacity and specialist departments of a larger agency.
My work follows a principal-led model. I stay directly involved in the business requirements, architecture, implementation, infrastructure, and production outcome. Katharina leads UX and interface design where the engagement requires it. We limit concurrent work so senior attention remains available throughout delivery.
If your company is planning a digital platform and needs direct senior ownership across strategy and implementation, I can help define the right system and deliver it with a focused team.
Thanks, Matija