Engagement model

Three models, by type of engagement

Not every project is contracted the same way. The model is not a commercial preference: it depends on how much uncertainty the scope carries on the day it is signed.

1. Fixed price, for a defined scope

Applies when the scope can be specified before starting: a Drupal 11 migration with a known content inventory, a portal with bounded functionality, an integration against a documented API. The deliverable is defined, estimated, and the price does not move unless the scope changes in writing.

This is the model public entities prefer, because it fits state procurement processes and allows budgeting ahead. It requires a short discovery phase, quoted separately.

2. Time bank, for continuous evolution

Applies when a live platform must keep growing and priorities will shift. A volume of hours is contracted and drawn against a backlog the client prioritises. Each period reports where the hours went.

It is the most efficient model when the client knows the direction but cannot write today's full task list. It avoids renegotiating every improvement.

3. Monthly retainer, for operation and support

Applies when the platform is already in production and what is needed is that it keeps running: security updates to core and modules, monitoring, incident response with committed times, and minor improvements. A fixed monthly fee against a defined service scope.

This is what sustains the GOV.CO platforms we operate. It includes a service window, a direct channel and a named lead.

What drives the cost

When we ask for context before quoting a figure, it is not a formality: these five variables explain almost all the difference between one budget and another.

• Volume and condition of the content to migrate. Migrating 200 clean nodes and migrating 40,000 with inconsistent legacy structures are different projects, even onto the same target platform.
• Number and maturity of integrations. A documented, stable API costs a fraction of an undocumented legacy system that has to be reverse-engineered.
• Compliance requirements. MinTIC's GOV.CO guidelines, Colombia's transparency law (Ley 1712 de 2014) and accessibility requirements add real implementation and verification work.
• Expected service level. Business-hours support and committed extended availability with short response times do not cost the same.
• How much the client's team takes on. Where an internal team operates and publishes, the Coresis scope narrows to engineering and mentoring.

How we get to a figure

1. First conversation. What platform you run today, what problem needs solving, and by when. No commitment, no form.
2. Technical review. We look at the current platform before proposing anything. For migrations and handovers this is essential: without seeing it, any figure is invented.
3. Proposal. Scope, recommended model, explicit assumptions, timeline and price. The assumptions are written down so it is clear what happens if one does not hold.
4. Adjustment. Scope is trimmed or extended until it fits the client's real budget. We would rather deliver a smaller phase one properly than an inflated scope that never lands.

What we say upfront

We do not publish rates because they would not be true: the range between an institutional portal with critical integrations and a bounded evolution on a healthy platform is too wide for a generic figure to help anyone. What we do is give the number quickly once we see the case.

We also do not charge for the first conversation or for the preliminary technical review needed to quote. And if the project does not fit what we do well, we say so: we would rather stay out of a project we should not take.

Next step

Write to us on WhatsApp or at contacto@coresis.info with three things: what platform you run today, what you need solved, and by when. That is enough for us to tell you in the first reply whether we fit and which model makes sense.

More context on the work: Drupal services, AI agency and project portfolio.