The situation
Kein is a real estate company based in Canada. They wanted a marketplace for real-world assets: actual buildings, represented and traded on a blockchain. Nothing existed yet. The product had to be built from the ground up, and it had to be done within a month.
A product like that has to handle three worlds that don't naturally talk to each other. Identity, because nobody should buy into a building without passing KYC. Banking, because the buildings and the money behind them live in the regulated financial system. Crypto, because the marketplace itself runs on-chain. Each has its own rules, its own failure modes, and its own idea of what "done" means.
On a one-month deadline, the usual instinct is to start coding on day one. That is how one-month projects become three-month projects: the code gets written fast, then rewritten, because in week three someone realizes the thing on screen isn't what the client meant. Kein's timeline had no room for a rewrite.
What Discovery found
Discovery ran one week rather than our usual two, because the whole engagement had to fit inside the month. We sat down with Kein's leadership and operations teams to map how the marketplace would actually run — what kinds of assets, how transactions would flow, who does what — and worked through the architecture with them in joint sessions. Four findings mattered:
- The product was a pipeline, not a feature list. KYC, bank-side asset management, the bridge and the marketplace each depend on the stage before. A misunderstanding in one stage breaks everything downstream, so the stages had to be designed together.
- The deadline ruled out a mid-project rebase. One wrong assumption discovered in week three would have cost the delivery date. Every assumption, constraint and dependency had to be written down and confirmed before any code was written.
- This was GRTC's first real-world asset project. We said so. Before designing anything, we studied how working real-world asset platforms move an asset and its money from the bank, across the bridge, and into a marketplace — and designed Kein's pipeline from that pattern rather than inventing one under deadline pressure.
- Testing belonged with Kein. The product's real test scenarios depend on Kein's own assets, banking relationships and users. Kein's team would run testing and send feedback to us.
Discovery output: a development document covering the requirements, the architecture — how the data is organized, how the systems talk to each other, and where they connect — and every assumption, constraint and dependency. We walked through it with Kein section by section until neither side had anything left to guess about. Kein confirmed it before the build started.
What we built
Week 1 — Discovery
The development document described above. No code. Its only job was to make sure the next three weeks were spent executing a plan instead of discovering one.
Weeks 2–4 — Build
Four connected pieces, built in pipeline order:
- KYC authorization. Clients are verified before they can participate. Nobody touches an asset without passing identity checks first.
- Real-world asset management through the bank. The building-backed assets are managed on the banking side, where the real money and the real ownership sit.
- The bridge. The link that carries assets between the banking side and the chain.
- The marketplace. Where verified clients find and trade the assets.
What happened at the deadline
We delivered within the one-month deadline. The functionality the project called for was designed and built, and Kein confirmed the product. Kein's team then took on testing, as agreed in Discovery, and sent their feedback to us.
"The team delivered the project within the timeline and helped Kein create new opportunities. I'm truly grateful, and it was a pleasure working with them."
What we did not do
- We did not run full end-to-end testing. Testing depended on Kein's own scenarios, so their team ran it and sent feedback to us. That was the agreement from Discovery, not an oversight.
- We did not start coding in week one. On a one-month deadline, a rebase halfway through would have cost the date. The document came first.
- We did not invent the pipeline. It was our first real-world asset project, so we learned the pattern from platforms already running in production before designing Kein's.
- We did not publish numbers we don't have. There are no transaction volumes or user counts here, because the product had just been delivered when this was written.
Numbers we can share
| Discovery duration | 1 week |
|---|---|
| Build duration | 3 weeks |
| Client's deadline | One month from engagement start |
| Delivery | Within the deadline (week 4) |
| Pipeline stages built | 4 (KYC, bank-side asset management, bridge, marketplace) |
| End-to-end testing | Run by Kein's team |
| Client sign-off | Development document and final product, both confirmed by Kein |
Numbers we don't have yet: transaction volumes, user counts, asset values, and performance or load-testing data. Not published: contract value, and the bank, KYC provider and blockchain used.
The pattern this case study represents
Tight-deadline builds that cross regulated finance and on-chain systems usually go wrong in one of three ways: the team starts coding before the scope is written down and confirmed, so week three becomes a rebase; the team builds each stage in isolation, so the handoffs between identity, banking and the chain break at integration; or the team pretends to know a domain it hasn't worked in, instead of studying the systems that already run in production.
Kein's engagement worked because the whole pipeline was written down and confirmed in week one, before any code existed.