Marcus is Kinetech's AI Mendix developer — the engine behind our one-week MVPs. Now available as a dedicated instance on your team: working your backlog, committing to your Team Server, and proving every release with evidence you can audit.
01 · What Marcus is
Marcus has built and delivered production Mendix applications for utilities, government programs, and regulated industries. Every build runs the full lifecycle — design, build, test, secure, document — and publishes the evidence.
See how the lifecycle works at our interactive explainer, and watch real build evidence land on the live Build Console.
02 · How it works
03 · You stay in control
Marcus is governed by fail-closed gates — the same discipline we apply to our own regulated-industry delivery. Four of those gates are held by you:
Every milestone starts from a written spec derived from your stories. You approve it before a line of the model is written.
Who can see and do what — every role, every entity — presented in plain English for your sign-off. Especially valuable for audited environments.
Two to three fully-styled design directions, derived from your brand, presented before pages are generated. You pick; Marcus builds to it.
A milestone reaches you only after all 9 quality gates pass — and it ships only when you accept it, with the evidence in front of you.
Every decision is on the record. Approvals, model changes, and build results land in a tamper-evident audit ledger — who, what, when, why. If your compliance team asks how a permission came to exist, the answer is one report away.
04 · The division of labor
| Who | Responsibility | Time |
|---|---|---|
| Your product owner | Writes stories; approves scope, permissions, and design; accepts releases | A few hours per milestone |
| Your Mendix developer | One short Studio Pro session per milestone from a checklist Marcus prepares (widget placements, module updates); reviews commits like any teammate's | ~1 hour per milestone |
| Marcus | Everything else: modeling, pages, logic, security, running the app, driving every user journey per role, accessibility & security scans, performance checks, in-model documentation, visual user guides | Continuous |
| Kinetech | Hosts and operates your instance; expert engineers handle anything unusual — with a response SLA when you take one | Always on |
Marcus runs and tests the application itself — your team is never asked to "pull the branch and see if it works." By design, your touchpoints are decisions, not chores.
05 · Quality & security
06 · Plans
Marcus used to be sold as named plans with a fixed monthly allowance. That was simpler and it was wrong: keeping a quiet application running and rebuilding a regulated system against a fixed date are not the same job, and charging the same for both means one of you is subsidising the other.
Verification effort per unit of work is not constant across those, so neither is the rate.
More is faster until it isn't. We size to where your model stops absorbing parallelism and tell you where that point is rather than selling past it.
Review effort scales with the amount of work, not the calendar — compressing the same scope concentrates the cost rather than spreading it.
What has not changed is who does what: you can drive the work yourself, or have Kinetech hold the quality gate, or hand over a whole scope as a fixed bid with the risk on us. The approval gates are yours in all three. Move the three factors and watch the range at what drives the price, or tell Marcus your situation and he will narrow it.
Every figure we show is a range with its assumptions beside it. Your applications, models and repositories remain your property.
07 · Getting started
| When | What happens | What we need from you |
|---|---|---|
| Days 1–2 | Your dedicated instance is provisioned and connected to your Team Server | Access tokens (we'll walk you through scoping them minimally) |
| Week 1 | Brand intake, design directions presented, permission model drafted | Your logo, 2–3 stakeholder hours for sign-offs |
| Week 2 | First milestone built, tested end-to-end per role, evidence published | Stories on the board |
| Week 3 | First release accepted; steady cadence begins | Your acceptance click |
08 · The questions you should ask
These are the questions experienced Mendix teams ask us — and should.
Yes — this is table stakes, not an afterthought. Marcus commits carry the full Studio Pro–compatible commit metadata Mendix uses for merging and building deployment packages, so your developers open the branch in Studio Pro, diff it, merge it, and build on it exactly as with a human teammate's work. If a commit didn't behave that way, we'd consider it broken.
Marcus works through Mendix's official surfaces — the Mendix Platform SDK, Team Server, and the platform's public APIs — and the output is a standard Mendix model, indistinguishable in kind from one built in Studio Pro. Every model validates with Mendix's own checker (mx check) before it's ever presented. Your apps remain ordinary Mendix apps on your ordinary Mendix licenses; nothing about your platform relationship changes.
Because Marcus is graded on it, every build. Naming conventions, documentation on 100% of authored elements (entities, microflows, pages — all of it), tidy domain models, lint rules, and a release scorecard are blocking gates — a build that produces an undocumented mess doesn't reach you. Ask us to show you a delivered model in Studio Pro; maintainability is easier to judge by looking than by promises.
The tokens are ones you issue, scoped to the minimum needed, stored in an isolated per-client vault, and revocable by you at any moment. Work happens on isolated branches — nothing reaches a shared branch without your acceptance click. Every action lands in a tamper-evident audit ledger, and Kinetech holds a per-instance kill switch. Worst realistic case: a bad branch you never accept, which gets deleted.
Your model lives in your Team Server repository — that never changes. Marcus's working copies run on an isolated instance dedicated to you, and commercial API terms with our AI providers exclude training on your data. Your application, its model, and its repository are contractually yours, full stop; off-boarding leaves you with everything and us with nothing of yours beyond build evidence you can export.
Better than most human processes, honestly — because everything is on the record by construction. Who approved each permission, when, and why; what every release was tested against; the security scan results per build; the accessibility grade — all in a hash-chained ledger and per-build evidence manifests. When an auditor asks "how did this access rule come to exist," the answer is a report, not an archaeology project.
They solve different problems. In-IDE assistants make a developer at a keyboard faster. Marcus is a governed delivery system — it takes stories, builds, runs the app, drives every user journey per role, scans, documents, and publishes evidence, end to end, without a keyboard. Use both: your developers with their assistant of choice, Marcus as the additional teammate carrying whole milestones.
It's capacity, not replacement — the product literally requires your team: your product owner holds the approval gates, and your Mendix developer reviews commits and runs a short checklist per milestone. What changes is what your senior people spend time on: architecture, integration decisions, and the backlog you never get to — instead of CRUD pages and test scaffolding.
Two honest paths. Platform actions that genuinely require Studio Pro are batched into the one short checklist session per milestone — planned, not surprises. Anything unusual beyond that escalates to Kinetech engineers (with an SLA when you take one). We won't pretend the list is zero; we will show you it's short, shrinking, and always visible in advance.
No. The work product is standard Mendix in your repository the whole time — cancel, and your team (or any Mendix shop) picks up exactly where Marcus left off, with better documentation than most human handovers: 100% in-model docs, visual user guides, the full test suite, and the audit trail. Lock-in would undermine the whole premise; portability is the proof the work is real.
09 · Next step
The fastest way to evaluate Marcus is to give it a real milestone from your actual backlog and judge the evidence. If the first release doesn't meet your bar, you'll know within three weeks — with a full audit trail of exactly what was built and how it was verified.
Marc Lehane · Solutions Architect / CTO, Kinetech · [email protected]
Kinetech Cloud · San Antonio, TX · How we deliver · What we do
Tell Marcus where you are — you will leave with a range, the assumptions behind it, and the answers that would narrow it. Nothing is charged, and nothing is quoted before we have read something of yours.
You are reading The offer, in full — deeper detail on step 2, How does it work?.
That is the mechanism. The fair response is 'prove it' — so next is exactly how a build has to prove itself.