Skip to content
ES, EspañolEN, English
Tell us about your project

Mexico City · UTC−6

We build what you get to keep.

We design, build and run digital platforms for companies. What we build for you is yours: you own the code, the docs and every account.

Tell us about your projectHow we work

Handover record

Model illustration

Owner
Your company
Provider
Korhy
Today
—
  1. 01RepositoryHanded over
  2. 02DocumentationHanded over
  3. 03AccessHanded over
  4. 04Infrastructure in your nameHanded over
Hands over · Korhy
Receives · Your company

Marking the record: 0 of 4

What you receive when a project closes. It is an illustration: it belongs to no client, and the date is today on your device.
02Services

What we do

Six service lines. Many projects combine several, and we help you sort them out.

Select a line to see it on the card.

Don’t see your case? Tell us about it.

03Who it’s for

Who we work with

Mid-size and growing companies, and the agencies that serve them, that need a site, a platform or a digital product that works in production.

They usually come to us when

  • They already paid for promises that never reached production.
  • They depend on a supplier who won’t hand over the code or the access.
  • They don’t know for sure what they have: where it is, whose name it is in and how it works.
Start with a diagnosis

What we don’t do

  • We don’t resell hosting or domains: they are contracted in your company’s name.
  • We do not issue certifications or compliance audits.
  • We don’t give legal or tax advice.

Each service publishes its own limits on its page.

04Architecture

How we build

A system is built in layers, and each one rests on others. Pick one to see what it is responsible for, what it depends on, what gets decided there, how far a failure reaches and what you receive at the end.

Content platformA public site your team edits and publishes without writing code.

  1. 01User experience

    Responsible for
    The pages the public reads and the editor your team publishes with.
    Depends on
    • Data and integrations
    • Infrastructure
    What gets decided
    Building pages ahead of time makes them fast and inexpensive to serve; in exchange, a change takes as long as a new build to appear.
    If it fails
    If a build fails, the last published version keeps being served. New content is delayed; the site stays up.
    What you receive
    Deployment in your namePasses to you

  2. 02Application logic

    Responsible for
    Draft previews, forms, search and the rules for what gets published and when.
    Depends on
    • Data and integrations
    • Security and governance
    What gets decided
    Little custom logic and more content-system configuration: less code to maintain, less freedom for bespoke editorial flows.
    If it fails
    The published site does not need this layer to display. If it fails, previews and forms stop and say so.
    What you receive
    RepositoryPasses to you

  3. 03Data and integrations

    Responsible for
    The content model (types, fields and relations), the files and the connection to your team’s tools.
    Depends on
    • Infrastructure
    • Security and governance
    What gets decided
    A strict content model prevents broken pages, but every new type needs a schema change instead of a free-form field.
    If it fails
    If the content system does not respond, nobody can edit or publish. Pages already built keep showing.
    What you receive
    Documented data modelPasses to you

  4. 04Infrastructure

    Responsible for
    Where everything runs: hosting, the delivery network, domains, and the test and production environments.
    Depends on
    • Security and governance
    What gets decided
    A managed platform saves running servers, in exchange for accepting its limits and the way it charges.
    If it fails
    Each version is a deployment that never changes after release: if one goes wrong, you go back to the previous one without rebuilding.
    What you receive
    Infrastructure in your namePer contract and model

  5. 05Observability and operations

    Responsible for
    Knowing what happens in production: logs, alerts, deployment history and what to do for each foreseeable incident.
    Depends on
    • Infrastructure
    • Security and governance
    What gets decided
    A few alerts someone answers are worth more than many dashboards nobody reads.
    If it fails
    If observability fails, the site keeps working, but blind. That is why an alert also fires when it stops receiving data.
    What you receive
    Operational runbookPasses to you

  6. 06Security and governance

    Responsible for
    The outer boundary: who gets into the editor, with which permissions, which secrets exist and where every change is recorded.
    Depends on
    • Observability and operations
    What gets decided
    Giving each person only the permissions they use takes longer when someone joins, but limits the damage of a compromised account.
    If it fails
    A leaked credential is revoked and replaced without touching the code, because secrets live outside the repository.
    What you receive
    AccessPasses to you
Internal operations appAn application your team uses to log, review and approve requests.

  1. 01User experience

    Responsible for
    The screens to log, review and approve requests, showing what each role can see and do.
    Depends on
    • Application logic
    What gets decided
    Asking the server for data on every screen shows the real state at all times, in exchange for depending on the network for everything.
    If it fails
    If a screen fails, the error stays there: the rest of the app remains available and the form keeps what was typed.
    What you receive
    Deployment in your namePasses to you

  2. 02Application logic

    Responsible for
    The rules of the process: the states of a request, who approves what and what is validated before saving.
    Depends on
    • Data and integrations
    • Security and governance
    What gets decided
    Validating on the server even when the screen already does duplicates work, but no rule depends on the browser behaving.
    If it fails
    An operation that fails halfway is undone entirely: a request never ends up in a state the process does not allow.
    What you receive
    RepositoryPasses to you

  3. 03Data and integrations

    Responsible for
    The database, its model (entities, relations and rules) and the integrations with the systems your company already uses.
    Depends on
    • Infrastructure
    • Security and governance
    What gets decided
    A relational schema with constraints protects consistency, in exchange for more careful migrations on every change.
    If it fails
    If an integration does not respond, the operation waits in a queue and is retried instead of blocking whoever is working.
    What you receive
    Documented data modelPasses to you

  4. 04Infrastructure

    Responsible for
    The services the app runs on, the database, the backups and separate test and production environments.
    Depends on
    • Security and governance
    What gets decided
    A managed database costs more than running your own, but backups and upgrades stop being your team’s job.
    If it fails
    Backups are restored in a separate environment to check they work before they are needed.
    What you receive
    Infrastructure in your namePer contract and model

  5. 05Observability and operations

    Responsible for
    Logs with context, grouped errors, alerts and a runbook for foreseeable incidents.
    Depends on
    • Infrastructure
    • Application logic
    What gets decided
    Logging every operation helps rebuild an incident, but forces a decision on which personal data must stay out of the logs.
    If it fails
    When an incident happens, the runbook says what to check first and how to go back to the previous version.
    What you receive
    Operational runbookPasses to you

  6. 06Security and governance

    Responsible for
    Sign-in, roles and permissions, secrets and the record of who changed what.
    Depends on
    • Observability and operations
    What gets decided
    Handing sign-in to your company’s identity provider makes offboarding simpler, in exchange for depending on its configuration.
    If it fails
    Every permission is checked on the server: a fault on a screen never exposes data the role must not see.
    What you receive
    AccessPasses to you

Illustrative diagram. It does not represent any client’s architecture.

05Method

How we work

  1. We look at your goal, what already exists and its risks before we propose anything.

    Output of this phaseDiagnosis document

  2. We put the scope, what is left out, the milestones and the cost in writing.

    Output of this phaseSigned proposal

  3. We settle the architecture, the flows and the interface with you before building.

    Output of this phasePrototype and architecture decisions

  4. We build in short cycles. At the end of each one you review a version that works.

    Output of this phaseA preview every cycle

  5. We go live and transfer the repository, the documentation, the access and the infrastructure to you.

    Output of this phaseHandover record

  6. If you sign up for it, we maintain and improve what is in production.

    Output of this phasePeriodic reports

Engagement models

  • A

    Fixed-scope project

    Scope, exclusions, milestones and price agreed in writing before work starts.

    Best for: when the goal and its limits are clear.

  • B

    Maintenance and operations retainer

    A monthly fee to maintain and improve platforms in production, with an SLA agreed in writing.

    Best for: when something that already works needs ongoing care.

  • C

    Block of hours

    Prepaid hours you use task by task, with a log of what was used.

    Best for: when the work is occasional or variable.

See the full method

06Deliverables

What you receive

When the work ends, it does not stay in our accounts. This is what you find in the repository and documentation that pass to you.

  • Repository

    Repository structure

    The code and its history, in an account your company owns, with a README that explains how to get it running.

    • README.mdHow to install, test and release
    • docs/architecture.mdThe layers and why they were chosen
    • docs/adr/One decision per file
    • docs/runbooks/Operating procedures
    See all

    Illustrative example. Not a client project.

  • Architecture decision record

    ADR 0004: managed database

    What was decided, what was ruled out and what is accepted in exchange, so whoever comes next does not have to guess.

    Status
    Accepted
    Context
    The app stores requests and approvals that cannot be lost, and the team does not run database servers.
    Decision
    Use a relational database managed by the cloud provider, in an account in the company’s name.
    Consequences
    The provider handles backups and upgrades. It costs more per month than running one and some extensions are unavailable.
    See all

    Illustrative example. Not a client project.

  • Runbook

    Go back to the previous version

    Steps anyone can follow in the middle of the night without knowing the code.

    1. 1Confirm the symptom in the alerts and note when it started.
    2. 2Find the last version that worked in the deployment history.
    3. 3If the failed version included a data migration, follow the migrations runbook first.
    4. 4Promote the previous version. Do not rebuild: release the same one that was already in production.
    See all

    Illustrative example. Not a client project.

  • Design token specification

    Design tokens

    Named values shared by design and code: change one and every screen changes at once.

    TokenValueUse
    color.textContrast ≥ 4.5:1Reading text
    color.actionContrast ≥ 3:1Buttons, focus and selection
    space.416 pxBase spacing
    size.target24 px minimumTouch and click area
    See all

    Illustrative example. Not a client project.

  • Release checklist

    Before releasing a version

    What is checked on every release, in the same order, so releasing never depends on anyone’s memory.

    • Automated tests green on the main branch
    • Code review approved by someone else
    • Migrations tested in the test environment
    • Release notes written for your team
    See all

    Illustrative example. Not a client project.

  • Test scenario matrix

    Scenarios: approving requests

    Every important rule has a scenario that checks it, including when something fails.

    ScenarioConditionExpected result
    Approve a requestRole without permissionThe server rejects and logs it
    Submit the formNo JavaScriptIt is sent and confirmed
    Save with an empty fieldKeyboard onlyThe error is announced next to the field
    Sync with another systemThe system does not respondThe operation waits in a queue
    See all

    Illustrative example. Not a client project.

  • Handover record

    Handover record

    The close: what passes to you and who signs it. It is the same record that opens this page.

    Owner
    Your company
    Provider
    Korhy
    Repository
    Handed over
    Documentation
    Handed over
    See all

    Illustrative example. Not a client project.

07Presence

Where we work from

We operate from Mexico City and work with clients in other countries.

  • Operations

    Mexico City

    --:--Time not available without JavaScript

    UTC−6 · 19.43° N · 99.13° W

  • Clients

    Mexico, United States, Spain, Estonia, and Japan

    Where our clients are. No names or sectors: each client decides whether we mention them.

  • Reference time
    Madrid
    --:--
    Tokyo
    --:--
    Miami
    --:--

    To coordinate with you. These are not offices or support hours.

  • Day and night

    An approximation calculated from your device’s UTC time; accurate to about one degree.

CDMX
15° grid: one hour

08Contact

Have a project in mind?

Tell us about your project

Book a call

Online scheduling is not available yet.

Contact

On the Contact page you choose what you need (a project, procurement, an agency or support) and find how to reach us.

Mexico City · UTC−6