Mobile apps · Web services · Internal systems
Built by agents. Backed by engineers.
We run our own agent pipeline — scaffolding, code, tests, deploy. Every merge and every release is approved by a named engineer.
You get production software with tests, docs, and CI included by default.
The repository and cloud accounts are in your name from day one, and the copyright transfers to you in full on acceptance and final payment. What data goes to which tool is agreed in writing before we start.
- One spec line produces both the screen check and the on-device run
- A green build is not enough to ship — we re-check the output before it goes out
Three things. Most engagements start with the first and end up at the third.
End-to-end product build
We take your spec and build the screens, the server, the database and the deploy pipeline. Mobile apps, web services, internal tools and back offices live in one structure.
The parts every project repeats — login, permissions, payments, notifications — come from implementations already running in production.
What gets written from scratch is your business logic.
No written spec yet? We start by shaping the scope with you — just tell us what you want to build and where things stand.
Test code, API and data specs, operations docs and the deploy pipeline are not line items on a quote. They are what you get.
What remains at the end is not one working app but a repository another team can pick up.
The twentieth screen matches the first
As screens multiply, the same button becomes five buttons and app and web drift apart.
We do not draw screens one at a time. The shared parts are built first and screens go on top of them — which is why the twentieth screen follows the same rules as the first.
The same 130+ components serve mobile and web the same way.
Operations and maintenance (annual)
What follows the build is longer than the build. After launch this becomes an annual agreement — a support channel, a release cadence, a monthly operations report.
Each month you get one page: what shipped, what was handled, what is still open. The numbers are counted from the repository, so you can recount them yourself.
And you can take it over at any time. Handover is not an end-of-contract event; it is an option that stays open inside the contract.
The repository and cloud accounts are created in your name and you hold the highest permissions from day one. Handover requests follow the notice period in the contract, and we do not put a clause in that lets us refuse.
The real risk in outsourcing is not a late delivery. It is being left with code nobody can touch.
So we publish the process, not just the result — all four stages are yours to inherit.
-
01
Scaffold
When every project has a different shape, the organisation pays the learning cost again at every handover — multiplied by the number of internal systems you run.
Every project starts from the same skeleton. Years later, a different team — or a different vendor — finds the same things in the same places.
-
02
Build
Login, permissions, payments, notifications: rebuild those on every project and you introduce fresh defects on every project.
Screens and business logic go on top of shared parts already proven in services running today. The only new code is the logic specific to you.
What comes out is ordinary code a person can read and change, not a proprietary format. You can keep building without us.
-
03
Verify — a person approves
Every feature ships with checks generated from its own spec — one that the screen renders correctly, one that the flow runs end to end on a real device.
Passing every check is still not enough to move on. A named engineer reviews and approves before anything lands in the main codebase — you get that name at kickoff.
When a security review or an audit asks who approved a change, you need an answer. Failures are recorded too, and your team can read all of it from day one.
-
04
Ship — we re-check what goes out
A build reporting success is not enough to ship. The output is checked again item by item, and one failure stops the release.
"The build passed but the screen was blank" is a real failure mode. Caught here it costs a rerun; caught by your users it costs far more.
Recurring failures like expired certificates are handled by automatic recovery. Deployment configuration is handed over inside your repository, so you can ship the same way without us.
It goes faster because repetitive work is handled by the pipeline and human time moves to interpreting requirements and verifying results — not because steps are skipped. The verification stage does not shrink.
That was the claim. Below is what you can verify yourself.
- 01The body is rendered on the server, without JavaScript.
- 02The Korean and English pages carry the same number of headings.
- 03No unhyphenated ten-digit-or-longer number appears in the body.
Visual parity check
Whether the app and the web really look the same is compared by machine, not by eye.
For each component the web rendering and the Flutter rendering are placed side by side and compared.
Their style properties — typeface, colour, border, spacing, shadow — are compared automatically whenever a component changes, and again every night. When values diverge, a comment lands on the pull request and an issue is opened for the nightly run.
Those comparison records live in a private repository, so we cannot hand you a link. We walk through the run history and reports on screen during due diligence.
This page
The site you are reading is one of the outputs.
Twelve checks had to pass before this page went out — that the required screens actually rendered, that no identifier we must not publish slipped in, that the Korean and English versions did not drift apart. One failure stops the release. Which checks apply is decided per project.
View the page source and you can confirm that now.
Who we are
The legal entity and the office address are printed at the bottom of this page.
And the structure that keeps your service running if we are gone — repository and accounts in your name from the start, a stack where the same language covers app and server, and a handover rehearsed once for real during the contract.
Which organisation, under which constraints, handed over what.
Case studies go up as client approvals come in. In the meantime, the closest thing to judge us by is how we build — what each stage produces, and who approves it.
If you ask, we can describe the shape and scale of current projects directly.
Worth knowing before we sign anything.
This works best when
- You are an early-stage team building your first service, and want scope shaping, the build and operations in one place
- You have no in-house developers, or very few, and need someone to run it after it is built
- You want mobile, web and internal systems in one structure
- You are rebuilding an existing service, or taking one over
- You want deliverables and ownership written down
Projects that require on-site staffing or work inside a separated network are not a fit for how we work. Ask us and we will say so plainly, and describe what to look for instead.
How it runs
Build projects run in four-week cycles. Each cycle ends with a build you can install and run. The first cycle exists to prove the deploy path is open, not to finish features.
Anything waiting on an external review or on material from your side is flagged at the start of a cycle and taken out of the schedule.
Progress is read from deployed builds, not from a percentage in a document.
Deliverable submission, an acceptance window, then a defect channel — with periods and scope written into the contract.
Engagement models
- Fixed price — for a defined scope
- Four-week sprints — when scope is adjusted as we go
Either way, payment is split across milestones.
Cloud usage is billed directly to your account and is not part of our fee.
What you receive
- The repository (in your name from day one)
- Architecture and data-structure documentation
- A runnable test suite
- CI/CD configuration
- Infrastructure configuration documentation
- An operations runbook
- A handover list for accounts, domains and certificates
- A licence list for the third-party open source included
Ownership
In the contractOn acceptance and final payment, the economic rights transfer to you in full, including the right to create derivative works. We do not exercise moral rights over the deliverables.
If a project uses CoUI, you also receive a source copy of the version used and an unrestricted licence to use and modify it.
CoUI contains components derived from third-party open source. The full licence texts and copyright notices are handed over together with that source copy.
For any third-party open source in the deliverables, we submit a licence list alongside the build output.
Before we start you get a written schedule of the tools. For each one it records what it is used for, the plan we are on, how the model is served, whether input is used for training and whether that answer comes from the terms or from an account setting, how long the vendor retains it, what is kept for abuse detection, what stays on a developer's machine, and a URL for the source of each answer.
Anything we have not confirmed is written as "unconfirmed" rather than left blank. We do not fill it in by inference.
Which data never enters the project is agreed before we start. Absent that agreement, four categories stay out by default: customer personal data, production data, unreleased business information, and production credentials.
AI tools are not the only route out. Issue trackers, design tools and collaboration tools also hold your specifications and business rules. The same schedule lists those services, what leaves for each, how they authenticate, and whether access can be scoped to this project alone.
When we add or change a tool, you hear about it in writing beforehand, and we do not use a tool you object to. What a vendor changes on its own — which provider a model is routed to, what a model alias actually resolves to, a policy revision — we cannot promise to flag in advance; we tell you as soon as we notice.
Development runs on test data by default. Where production data is unavoidable, we get the scope, the period and the named handler approved in writing first, keep it to the minimum, and process it outside the workspace the tools can read.
The repository and cloud are both your accounts, so backups follow your policy and we hold no separate copy of your data. What does persist is a repository clone and tool session history on developer machines; at the end of the project we delete those and confirm the deletion in writing.
On request we send back a security questionnaire setting out the tools we use and how data is handled. A security undertaking is signed after that review, together with the NDA.
Frequently asked
Can AI-written code actually be maintained?
The output is ordinary Flutter and Serverpod code, not a special format.
Every project starts from the same template so the structure does not drift, and tests and documentation ship with it.
The standard we hand over to is: another developer can take the repository and continue.
What happens to our service if cocode disappears?
The repository and cloud accounts are in your name from day one. We are not lending them to you.
The app is Flutter, the server is Serverpod, the database is PostgreSQL. App and server are the same language, so a Flutter developer can read the server code. The data is standard PostgreSQL and moves to any team as-is.
If a project uses CoUI, we hand over a source copy of the version used and write an unrestricted licence into the contract. The standard is that it builds and deploys without access to our accounts.
CoUI contains components derived from third-party open source. The full licence texts and copyright notices are handed over together with that source copy.
After the first release we schedule one handover rehearsal: your team, or a third party you designate who has signed an NDA with us, reproduces the build and deploy in a fresh environment without our help. Production is not touched.
Whatever does not reproduce, we fix in the documentation and scripts and check again — finding those gaps is the point of the exercise.
Is our code or spec used to train external AI models?
We send parts of the code and the spec to agent tools in order to build. We say that first.
Which data stays out is agreed before we start. Absent that agreement, four categories are out by default: customer personal data, production data, unreleased business information, and production credentials.
AI tools are not the only route out. Your specifications and business rules also pass through issue trackers, design tools and collaboration tools. The same schedule records what leaves for each service and whether access can be scoped to this project alone.
Some integrations cannot be scoped that way. Mail, file storage and messenger connections reach a whole account, not one project — for the duration of the work we disconnect them.
Which tools we use and under what terms is provided as a list before kickoff. When we change one, you hear beforehand and we drop anything you object to; when the vendor changes it, we cannot know in advance and tell you as soon as we notice.
We sign an NDA, and on request we answer item by item in a security questionnaire.
Who owns the code?
On acceptance and final payment the economic rights transfer to you in full, including the right to create derivative works. It is written into the contract.
Can we use our own standard contract?
Yes. We work from your template.
Five items we will state our position on first and ask to adjust: IP assignment, deliverable scope, defect-liability period, limitation of liability, and how delay damages are calculated.
The rest we generally accept as written — and if there is a clause we would not be able to perform, we raise that clause specifically.
We do not have a spec yet — can we still enquire?
Yes. Tell us what you want to build and where things stand, and we start by shaping the scope together. Once the scope holds, you get the quote and the schedule.
How is the quote calculated?
Scope first, then the number. Tell us what you want built, the timing, and a rough budget range, and you get a scope proposal alongside the quote.
If scope is not settled yet, we propose on a four-week sprint basis.
How long does it take?
It depends on size, but we cut it into four-week cycles and deliver a working build at the end of each.
After the first cycle you can see the actual pace and we adjust the schedule together.
How does maintenance work?
After launch it becomes an annual agreement — support channel, release cadence, monthly operations report.
If you decide to run it yourselves, it converts to handover at any point.
Do you work with clients outside Korea?
Yes. We work remotely by default and documentation is delivered in English on request.
Contracts, invoicing currency and time-zone overlap are agreed before kickoff.
What if we move to another vendor mid-project?
We do not make handover conditional on our consent. We accept the request per the notice period in the contract, settle the work completed, and organise the handover documents and runbook as of that date.
If we enquire now, when could you start?
It depends on what is running at the time. We tell you the earliest start date when we reply, and scope work can happen in the meantime.
Not sure yet what to build? That is fine.
Tell us where things stand and we will shape the scope together. Someone will get back to you within two business days.