How does a first engagement start?

It starts with a two week discovery. We read your systems, your data and the commercial goal, then write down what we would build or change and why. You get that document whether or not you continue with us.

Who do you work with?

Companies that already have something running, or a clear decision to build: product teams, operations teams and founders who need engineering they can hold accountable. We work with teams across Europe, Asia and North America, in English.

How do handover and documentation work?

Documentation is part of the work, not a phase at the end. Architecture notes, environment setup, deployment steps and a runbook live in your repository, and access sits in your accounts from the first week, so you can take the work to another team at any point.

What if we only need one of the three lines?

That is a normal engagement. Each line stands on its own, and we say so if a request would be better served by keeping your current supplier. Nothing here requires you to buy all three.

How do you price shaped work?

Discovery is a fixed scope for a fixed fee. Build work is priced per increment once discovery has defined it, so you approve a cost against a described outcome instead of an estimate. Run and grow is a monthly retainer sized to the platform and the response time you need.

Where is the company registered?

In Hong Kong, as AURORA COGNITIVE TECH LIMITED. That is our only registered jurisdiction, and we work with teams internationally from there.

Services

Three lines of work, one team

Most partners cover one of these and hand you the seams. We build the product, run the infrastructure under it and generate the demand against it, with the same people accountable across all three.

Book a technical assessment

30 minutes with an engineer, no sales call

Split ownership costs you twice

A build agency finishes and leaves. A managed provider inherits a system it did not design. A marketing team spends against a product neither of them can change. Every gap between those three becomes your job to manage, in meetings you did not plan for.

We keep the three lines under one accountable team. The people who know why a decision was made are still there when it needs to be revisited, and a request never stalls while two suppliers agree on whose side of the line it sits.

Seams we remove

Build to run handover
The team that wrote the code also sets up the pipelines, the alerts and the runbook, so nothing is explained twice to people who were not there.
Incident ownership
One rota covers the application and the infrastructure under it, so an outage is investigated instead of forwarded.
Product and demand attribution
Analytics are wired by the same engineers who ship the release, so a change in the funnel can be traced to the change that caused it.

The three lines

What each line owns

Software development

We start from the workflow you actually run, not from a template. That means a working increment early, a typed codebase, tests on the paths that would hurt if they broke, and the integrations that keep the system fed with real data. Handover is written down as we go, so the next engineer does not need us to explain it.

Software development →

IT services

We take responsibility for the platform under the product: infrastructure described as code, release pipelines that anyone on the team can run, access that can be reviewed, monitoring that points at a cause, and security work recorded as evidence rather than assertions. This applies to what we built and to systems you already own.

IT services →

Digital marketing

We treat demand as an engineering problem. Measurement is fixed first, then search and answer engine visibility are built on pages that are structured for both readers and crawlers, and paid channels are judged on qualified conversations. Every change is instrumented, so you can see what moved and what did not.

Digital marketing →

Starting points

How the lines combine

Which lines engage, in order

01IT services first: we read the running system and take over operations.
02Software development second, once we know which parts fight us weekly.
03Digital marketing only after the platform is stable enough to promote.

What the first month looks like

Week 1: access review, inventory of environments, dependencies and third party accounts.
Week 2: monitoring and alerting wired to a rota, with a written escalation path.
Week 3: pipelines rebuilt so a release is repeatable without the original authors.
Week 4: a risk list you can act on, ordered by what would break first.

Engagement models

How engagements are shaped

Discovery sprint

For deciding what to build, or whether to build at all.

We read the systems, the data and the commercial goal
A written scope with the decisions and their reasons
Architecture and delivery plan you can take elsewhere

Minimum sensible duration: two weeks.

It ends with the document. Either we continue into a build engagement or you keep the plan and stop there.

Build engagement

For getting a working system into production.

A working increment first, then reviewed steps
Tests on the paths that would hurt if they broke
Environments, pipelines and documentation as part of the work

Minimum sensible duration: eight weeks.

It ends when the scope is in production and handed over, with the runbook written. Ongoing work moves to the run and grow model.

Ongoing run and grow

For keeping the platform healthy and putting demand through it.

Monitoring, incident response and a named escalation path
Maintenance, upgrades and security review on a fixed rhythm
Search, answer engine and paid work once measurement is honest

Minimum sensible duration: three months, reviewed monthly.

It continues month to month. You can stop it with notice, and the documentation and access stay with you.

Questions

Common questions

Next step

Tell us which line you need first

Start a conversation

One reply from an engineer, usually within one business day.