UBIKON.ioOur engineering standards
This page documents how Ubikon actually builds — the coding conventions, security checklist and delivery process applied to every engagement, published so a CTO or technical founder can judge the work before a scoping call rather than after signing a contract.
The method
The Glass-Box Method.
Most agencies are black boxes: you see a proposal going in and an invoice coming out. Ubikon publishes the box. Four pillars, each one a page you can read before ever talking to us.
| Pillar | What is open | Where it lives |
|---|---|---|
| Open prices | Real ranges for every service line and an ungated calculator — no contact-for-pricing | /pricing |
| Open progress | A build you can open every week, with a video walkthrough and changelog | /how-we-work |
| Open standards | The coding conventions, security checklist and delivery process — this page | /standards |
| Open exits | Leave at any milestone with working code, your IP and documentation | /guarantee |
Nothing on this table is new — every pillar was already published on its own page. Naming the method just means you can point at the whole box at once.
Code standards
What ships in every codebase
TypeScript / Python — typed, strict, no exceptions
TypeScript projects run in strict mode with noUncheckedIndexedAccess enabled — array and object access that could be undefined is a compile error, not a runtime surprise. Python services are typed with mypy or Pydantic models at every API boundary. Neither language ships with type errors silenced to make a deadline; the deadline moves, or the scope does, before the type safety does.
Every PR is reviewed before merge
No solo-merges to a main branch that deploys. AI-augmented delivery accelerates the writing of code, not the review of it — a second set of eyes (human or a structured automated review pass) checks every change before it ships, the same discipline a senior engineering team runs regardless of how fast the first draft arrived.
Tests are part of the deliverable, not an afterthought
Business logic gets unit tests. User-facing flows get integration or end-to-end coverage. “It works on my machine” is not an acceptance criterion — a documented, repeatable test suite is, so a bug fixed once doesn't quietly return three sprints later.
Documentation ships with the code, not after it
API routes are documented at the point they're written. Architecture decisions that aren't obvious from the code itself are recorded in a decisions log, not left to be reconstructed from git blame six months later by whoever inherits the project — including your own team, after handover.
Security checklist
What's checked before launch
Every engagement is checked against this list before a production launch — not as a final audit, but as a running discipline through the build:
- Secrets (API keys, credentials) live only in environment variables or a secrets manager — never committed to a repository, ever, no exceptions for “just this once.”
- All user input is validated at the API boundary (Zod on the TypeScript side, Pydantic on the Python side) before it touches business logic or a database query.
- Authentication and authorization are checked on every protected route server-side — client-side route guards are a UX nicety, never the actual security boundary.
- Dependencies are audited in CI; known-critical vulnerabilities block a merge rather than getting silently accepted.
- Security headers (HSTS, X-Frame-Options, Content-Security-Policy, Referrer-Policy) are set by default on every deployed site, not added reactively after an incident.
- Rate limiting sits in front of any public-facing API route that accepts user input, particularly anything that calls a paid third-party API (payment processors, LLM providers) on a user's behalf.
- Personally identifiable information is scoped to what a feature actually needs — collected data has an explicit purpose, not a “might be useful later” justification.
Delivery process
How a project actually runs
Scoping call, then a written spec — not a verbal agreement
Every engagement starts with a 30-minute scoping call and ends that stage with a written, line-item spec: features, timeline, milestones, payment schedule. If a line item looks wrong to you, you get the comparable prior builds behind the number, not just an adjusted quote.
Weekly working builds, not a reveal at the end
You receive a build you can actually open every week from week one, plus a short video walkthrough and a written changelog. If something is off-track, it surfaces in week two, not in a “final delivery” meeting where the only options are accept it or start over.
Launch includes infrastructure, not just code
Store submission (for mobile), CI/CD, monitoring and basic uptime alerting are part of launch, not a separate line item discovered after the code is “done.” A monthly plan is available if you want continued iteration after v1, but it is never required to receive a working, deployed product.
Full IP transfer and repository handover, always
Every contract includes 100% IP transfer on work delivered — not only on a completed project — and a private repository handover. There is no version of this engagement where Ubikon retains rights to code built for you, and an NDA is signed before scoping begins if you want one in place first.
Read next
See the numbers behind these standards.
Standards are easier to trust when the pricing and comparison behind them are just as public.
Judge the work, then talk to us
Standards are easy to claim. Ask us to defend any line above.
Book a 30-minute scoping call and bring the hardest question on this page — we'd rather answer it before you sign anything than after.