From stalled development to a product ready to demonstrate.
A stalled DID/VC platform was redesigned from scratch. Spec-driven development, parallel AI sessions, and adversarial review loops enabled two engineers to rebuild the beta in approximately three months, compared with six people and six months for the initial development.
- Team size: 6 → 2 people
- 1/3
- Development time: ~6 → ~3 months
- 1/2
- Ready for customer proposals and PoC discussions
- Beta
Project overview
The project was a SaaS platform for issuing digital credentials across different industries. DIDs identify entities involved in a credential, such as people or organizations. VCs are digital credentials whose origin and integrity can be verified.
- Product
- A SaaS platform for issuing DIDs and VCs
- Responsibilities
- Standards research, architecture, DID/VC issuance and verification, smart contract implementation, and restructuring the development team
- Involvement
- Joined the initial design phase as a backend engineer. Later led the rebuild following discussions with the business lead.
The architecture needed attention before more features could be added.
After roughly six months, the initial product remained an unstable beta, more than three months behind schedule. It used proprietary DID and VC specifications that did not comply with W3C standards. Smart contracts also handled organization permissions and credential issuance permissions, making the architecture difficult to extend.
The product required a native app and wallet integration. Contract addresses had to be updated manually during deployment. Following discussions with the business lead, we decided to build a separate system from scratch rather than carry over the existing architecture.
What changed in the rebuild
| Area | Initial development | After redesign |
|---|---|---|
| Credential specifications | Proprietary DID and VC specifications | Implementation based on W3C documents and standards. External tools used to check DID resolution and credential formats. |
| Access | Native app installation and wallet integration | A web app, with support for use as a LINE Mini App. |
| System architecture | Logic spread across Next.js, NestJS, Go, React Native, and other components | A structure centered on Next.js and NestJS, with a limited role for smart contracts. |
| Smart contracts | Used for organization permissions and VC issuance permissions | Optional VC anchoring to support tamper detection. |
| Upgrades | Manual contract address updates during deployments | The UUPS Proxy Pattern keeps the reference address stable when upgrading contracts. |
Combining AI development practices to rebuild a DID/VC platform with two engineers in about three months.
Keita and a junior engineer rebuilt the platform by adapting both its architecture and development workflow to the specialized DID/VC domain. A simpler architecture broadened what the junior engineer could handle, while parallel AI implementation, automated tests, and cross-review supported the shorter development period.
- An architecture the junior engineer could work with
- The redesign reduced the range of technologies required, enabling a less experienced engineer to handle the frontend. Keita took responsibility for components requiring specialist knowledge, including DID/VC issuance and verification and smart contracts.
- Parallel implementation with spec-driven development and Git worktree
- The team shared spec-driven development skills created by Keita. Instead of repeatedly giving detailed instructions in each vibe-coding session, AI worked from specifications and a shared development workflow. Git worktree provided separate working environments so multiple AI sessions could implement changes in parallel.
- Quality checks through CI/CD and GAN-style adversarial loops
- CI/CD quality gates and unit tests verified behavior. Codex and Claude Code were also used in a GAN-style adversarial review loop: they identified problems in each other’s implementations, followed by corrections and re-review. Automated tests and reciprocal AI review helped detect and resolve code issues while implementation proceeded in parallel.
The initial team had six people on the development side: a PM, three engineers, Keita, and a tester, plus a business lead.
Built for integration with other services.
We prepared a developer portal with API references for external vendors. An MCP interface also allowed AI agents to issue DIDs and VCs, providing another way to use the platform beyond the web interface.
- Web app / LINE Mini App
- External services / API
- AI agents / MCP
A simplified conceptual diagram showing integration paths and responsibilities.
Checking standards and external formats
We referenced W3C documents and standards and implemented support for did:key, did:web, and did:ethr. During development, Universal Resolver was used to check DID resolution, and Paradym’s SD-JWT VC tool to inspect credentials in that format.
Ready for customer proposals and discussions.
The product that had taken a six-person development team approximately six months was rebuilt from scratch by two people in approximately three months: one-third of the team and half the development time. With PoC customers already present, the project moved from stalled development to a beta ready for proposals and concrete discussions about its use.