Changemkr: four systems became one platform
The studio’s relationship to the client
Changemkr is a platform Torn Studio owns part of. The studio held the product role from January 2025 to June 2026 — first as CPO, later on a fractional basis — and built in the codebase alongside the role. Work after June 2026 belongs to others and is left off this page.
Short answer
Torn Studio held the product role at Changemkr and owns part of the platform. Four inherited systems became five deployed services around one schema authority of 63 tables, and eight AI environments share a single LangGraph service with versioned prompts. This page describes the work up to June 2026, where the studio’s period ended.
The brief
Changemkr needed one platform where survey, analysis, planning and follow-up hung together, with AI running through the whole chain. The product then lived in four codebases that had grown apart and described the same concepts differently.
What made it hard
- The planning hierarchy existed as seven separate models in a Django API, and the same word meant different things across the four systems — one change took four edits by four people who each read the model differently.
- The AI layer spoke its own vocabulary, so the assistant proposed objects the canvas could not accept. That was one of two blockers standing before launch.
- The Python service’s database models were maintained by hand beside the TypeScript-defined schema, so the two descriptions of the same tables could drift apart silently.
Figures a reader can count
- 4inherited systems merged
- The migration report in the repository lists them one by one, with what each owned and what replaced it. A build script holds imports from them at zero.
- 63tables under one authority
- Countable in the schema directory at the June boundary. The Python models are generated from the same definition, and a gate fails the build once they diverge.
- 5deployed services
- Web, business API, AI service, admin console and a job runner. All five appear in the repository’s compose file and in the Azure infrastructure code.
- 8AI environments on one service
- Countable in the prompt registry. Each environment carries its own model, its own tool set, and its own prompt versioning with one-click revert.
- 80end-to-end specification files
- Countable in the test directory at the June boundary. The page quotes the file count, because the repository has itself withdrawn its pass-rate figure from that period.
How it was done
One schema authority, everything else derived
Drizzle was made to define all 63 tables, and the Python service’s models are generated from that same definition by a script. A build gate compares the generated file with the committed one and fails on divergence, so two systems describing one table differently cannot be committed.
Hard domain boundaries
NestJS owns business data — accounts, organizations, surveys, plans. The Python service owns the AI domain — threads, embeddings, memory, the supervisor. The web app calls both directly, and the boundary is written in plain language in the repository’s instruction file, which makes it a decision other people can follow.
Seven models became one
The planning hierarchy was reshaped into one table with a type discriminator, plus a table for key results and one for relationships. The vocabulary was closed, and the AI layer was made to speak exactly the words the canvas uses. The blocker covering that closed on the tenth of June 2026.
Gates carry the boundaries
One script holds imports from the inherited systems at zero and fails the build on the first relapse. Another fails the schema once the generated models have drifted. The consolidation holds because it is checked on every change.
The organization’s own data, in the prompt
Survey results, weak motors and the organization profile are now injected into the system prompt for the environments that need them. That information used to sit behind tools the model had to choose to call, which it sometimes skipped.
Stack
- NestJS
- FastAPI
- Next.js
- Drizzle ORM
- SQLAlchemy
- LangGraph
- PostgreSQL
- pgvector
- BullMQ
- Azure Container Apps
The limits of this proof
This shows that four systems can be merged into one and held together by gates. It shows nothing about a market: the platform had not launched at the June boundary, the verdict in the repository’s own readiness log was deployable with caveats, and one of those caveats was a manual security task that no code closes.
Evidence
What this article rests on — a measurement we took, a dated source, or a decision we made and what it cost.
- Measurement
How many tables the single schema authority defines
Measured on: The Changemkr schema directory at the June boundary
Method: Count the pgTable calls in packages/database/src at the last commit in June 2026.
Result: 63 tables
- Decision
Let one schema define every table and generate the Python service’s models from it.
What it cost: Every schema change now needs an extra generation step before it can be committed, and a hand-edited model fails the build even when it is correct.
- Decision
Collapse seven planning-hierarchy models into one table with a type discriminator.
What it cost: The database can no longer separate the object types with columns of their own, so the rules about what may sit where moved up into the application and need tests of their own.
Common questions
- Is Changemkr a Torn Studio client?
- The studio owns part of the platform and held the product role there, which the page states at the top. The difference matters: an engagement for someone else and a product the studio part-owns are different claims, and a reader is owed the distinction before any result.
- Why does the case stop in June 2026?
- The studio’s product role ran to then. The platform has developed further since under other hands, and counting that work would be taking credit for someone else’s. Every figure on the page is measured at that boundary and can be checked there.
- Why is there no figure for how many tests passed?
- The repository re-measured its suite in August 2026 and withdrew the earlier figure as void. A number the source has retracted has no place here, so the page quotes what was stable at the boundary: tables, services, AI environments and specification files.
- What does one schema authority mean in practice?
- That a single definition holds all 63 tables and everything else is derived from it. The Python service’s models are generated by a script, and a build gate fails once the generated file and the committed one diverge. Two systems describing one table differently becomes impossible to commit.
- How much of the code did the studio write?
- The studio built large parts of the product during the period and originated most of the ideas and features, while others also worked in the codebase. So the page claims a role and a period, and the figures describe the delivered system at the boundary.
- Can a client buy this kind of work?
- Yes, in two shapes. Consolidation and AI integration sit under AI and automation; the product role — decision material, prioritisation, architecture calls — sits under Product Management. An engagement opens with a fixed-price review before anything gets built.
Tell us what you want to build
Thirty minutes, free of charge, and a straight answer on whether we are the right studio for it.
A reply within a day, a written proposal with a fixed price within three days, and you decide at your own pace.
Satisfaction guarantee