I built an architectural model of how the system actually fits together: engines, phases, layers, and a mission structure on top to handle authority levels between them. Leaned into a NASA/mission metaphor as the backbone to help me understand what is needed to make this ambitious project actually reach maturity. NASA is a strong role model for a people, process and machine system run at a high level, even if the domain is completely different.

Built an inventory of every part of the system mapped against typical NASA mission lifecycle, then split it into five stages: pre-flight, vehicle, ground control, in-flight, post-flight. That turned a vague list of gaps into specific missing pieces as I was able to go granular. The shape is getting clearer, though the more I map, the more the system reveals what's still missing.

Progress is good, but honestly it's getting harder. The problem keeps growing and I'm hitting the edges of what I know, so a lot of this is studying my way forward and getting advice from my peers. Technically it's a really interesting problem though, and I'm genuinely enjoying working on it. I am trying to feel good about taking longer thinking phases versus just coding as I know it will benefit the design long term.

Finished the CLJS↔TS bridge rebuild. Moved the runtime to direct ESM imports across web, desktop and mobile, so there's one runtime now with proper types at the boundary and hot reload per module. Felt good to ship something concrete after weeks of audit work.

Pulled negotiation and spatial out of the layout engine into their own engine. I'd been treating it as a layout concern but it kept poking out into other areas, so giving it its own space was overdue.

Spent the rest of the week locking things down so parts stop bleeding into each other. Proper gateways between engines, narrower types, less accidental coupling between mechanisms.

Good spot to be in. The foundation can take more weight now, and I can start moving faster on what gets built on top.

Restructuring how the system is organised - splitting the lifecycle into five distinct phases instead of four, and moving each one into its own folder. Broke a lot of things along the way, so most of these two weeks have been an audit pass.

Slow on paper, but the structure is bending the right way. Work is very pedantic and I am enjoying it for now.

April is here. I'm starting to feel the pain of repetitive work. Porting the same patterns over and over is boring, but skipping this work will cost more later.

The reason we're doing it: we're restructuring how the system thinks about its own work. Instead of one big capability layer, we now have a lifecycle - four distinct phases from the moment something enters the system to when it's delivered across different engines. It's architectural shift, but the real effect is immediate: it's already showing me places where the system was quietly doing too much at the wrong place. Isolating each phase should create more control over capabilities.

The Clojure port is finally done. It's been slow to do it one by one, but the system is working and we made it to the other side. Yay!

Now rebuilding the architecture to be headless and data-first. I'm refactoring components to be more modular and reusable. It's dense amount of information, my head is burning most days because this is all new for me. Researching I found someone else independently arrived at the same approach regarding headless clojure/react systems, which made it feel less crazy. Small validations like that matter when you're doing an unconvential approach.

Third attempt at moving to Clojure. This time taking a different approach - porting file by file with parity tests while keeping the old system running. Successfully moved first folders while everything stayed connected. Small win, but it proves the approach works.

Ported layout-engine and orchestrator which are bigger pieces. It's slow going, but the migration is coming along. Mentally tough week - feels like churning butter on the same thing over and over and sometimes I feel like I am not building anything.

To add more pressure, we hit a setback with tooling. Pricing changes on Windsurf broke my workflow completely. Now researching alternatives to get back into a good flow. This always somehow seems to happen when you find your groove, feels like the universe is testing you. Good thing is that we are resilient and there is always a way.

TypeScript and React are hitting their limits for what we're building. The project is fundamentally data-driven, and the current stack feels too verbose. Started exploring Clojure as an alternative for core parts of the system.

First attempt was rough, but it taught us a lot - archived it as a learning pass. The next rebuild should be cleaner now that we understand the patterns better.

Added visual guides to watch the system work. Detaching mobile for now - it needs to work fundamentally different. Building the system for it, but won't plug it in fully until desktop is solid.

The system is getting complex enough that we needed to pause and clean house. Spent the week going folder by folder, understanding how decisions flow through the architecture. It's above my paygrade at the moment, but that's expected - just need to find better ways to manage this complexity.

Switched our tooling to Biome and did a full project reorganization. Upgraded to React 19 and the latest React Native versions - we were falling behind and getting into compatibility trouble. The native and web platforms now share the same logic source, which should cut down on the duplication we've been fighting.

Sometimes you need to step back and tidy up before you can move forward clearly.

Experimenting with making layouts more fluid and adaptive. Built a new approach that eliminates unnecessary component re-renders when layout changes. Added morphing capabilities so layout transitions animate smoothly into new positions.

Connected our work to academic research and found interesting parallels with what the science community is exploring. The architecture is becoming more declarative, which opens up new possibilities for how the system can evolve.

Started exploring how AI can understand and manipulate our layout system. Early experiments are promising - being able to adjust components through natural language feels like the right direction.

Explored how modes could be more dynamic and adaptable. Rebuilt our component library with a more modern design system - new tokens, cleaner structure, better consistency across the board.

Had a productive session aligning on the product vision now that the technical fundamentals are in place. The pieces are starting to fit together in a way that makes sense. We can see the path forward more clearly now.

Created flow-engine, a parallel system to layout-engine that maps behavior across the app. This enables reusability of components, features and flows. Modes can now switch using flows - the video shows it in action.

Restructured everything into Blocks - components, features and flows now live here. Added navigation context to move between flows and modes. Connected two modes via blueprint file in atlas and created unified App entry point so we don't have to update desktop/mobile/web individually.

Refactored to three-pillar approach: [mode].layout.ts, [mode].traits.ts, [mode].flows.ts. Added comprehensive state system inside the flow system. Built component manifest system - modes now declare which sections/variants activate per component via trait config. Components and modes can communicate about what should be activated where.

The architecture is starting to look really good conceptually. We can see how it could work in the future. Understanding the fundamentals much better now, and how to work with AI to speed up development. The system seems to 'understand' the build better too. This setup should make product building much faster and more efficient.

Introduced the 'atlas' concept - think of it as the map of the entire app. Defined what a mode actually is: a collection of intent-based actions that create consistent output. Built Inventory Mode with a simple counter as our first real test of this architecture. We are replacing how pages work with modes, flows, features and components. This will enable us to build anything without duplicating work as all the elements are self-contained. Atlas concept will combine these individual pieces into a main connection.

Started adding infinite slot nesting (A1, a1, 1a1, 2a1) but faced some challenges and parked it for now. Added React Native parity with .native.tsx files. Refactored atlas/platforms to atlas/config and created blueprint.ts for orchestration. Pushed simplified-web into main - we're committed to this direction now.

Separated validation from negotiation. Validation rules now run independently in layout-engine. Fundamental rules exist without negotiation engine.

Started components for negotiation engine before we activate negotiation on them. We now face the challenge of getting modes to be more comprehensive to replace pages and routes if possible.

Rebuilt layout on coordinate system for AI generation. Bending flexbox to act like grid when needed. Negotiation engine got too complex. Reverted to stable version.

Added slot rules: parent-child height/width override, dimensional independence at each level. Fixed width/height declarations. Some rules solid, others will surface bugs.

Exploring mode stacking for overlaid tooling across multiple viewports. Vic building 'foundation' - AI compliance platform on same framework as Diskura (magicbinder). We are running parallel projects to test the system.

Diskura should be the platform for Vic to manage his project eventually as a founder. First real test subject. We are still far away but it's fun to have a parallel race :)

Confirmed layout engine runs on all platforms. Web, desktop, mobile all working. Created new spatial system with React Native platform detection and fallback handling.

Built resolver and negotiation layer structure. Components use priority-based space decisions: who stays, compresses, or hides. Added container queries, semantic grid spacing, and unit tests for spatial logic.

Implemented slot limitations and validation. Multiple viewports within a window. Split mode support across all platforms.

Wrote Product Vision doc clarifying architecture: magicbinder (framework) → Diskura (interface) → tools. This structure lets us build complex layouts systematically.

Stripped down MVP to build negotiation engine. Only 2 modes and 2 components. They interact through layout engine and negotiate back and forth. Created simplified-mvp branch to keep this clean.

Started building mobile support with Expo alongside web and desktop. Good choice to start with as there were conflicts in layout architecture. Better to mitigate early.

Refactored the platform. Moved layout engine to core. Switched from grid to flexbox for better cross-platform rendering.

On strategy side, researching how others approach software intent versus traditional tool-first design.

Back from Japan and settling into our new flat in London. The trip was incredible - exploring Tokyo, Kyoto, Osaka, and soaking in the culture gave us fresh perspective. Moving into a new place right after takes more time and energy than you'd think even when just a street away, but we're finally getting comfortable.

We've been chipping away at small updates where we can. Fixed some bugs in the window delegate system, refined a few UI components, and did general maintenance work. Nothing major, but keeping things moving forward even during the chaos of a move.

Now we're taking a proper break for the holidays. Time to recharge, and come back fresh in the new year.

To everyone following along - thank you for being part of this journey. Wishing you happy holidays and a wonderful start to 2026. See you in January with renewed energy and more updates!

Testing our work rhythm from Japan this week. Not optimal conditions, but good practice for staying productive on the move. It was a wonderful trip so far.

Had strategic conversations about 2026: building a services/consulting business in parallel to the platform. We want to bootstrap as long as possible and own our relationship with customers to build something solid, not add junk to the market.

The idea is to productize what we need for our own work first. When we find a specific use case, we can service clients quickly without compromising quality. This helps us recognize true market needs.

We're generalists more than specialists - a pro and a con. This adaptability enables pivoting but we might miss the depth sometimes needed. We realized we need more knowledge about current market needs to fully lock in.

Building for ourselves first keeps us motivated. We'll reach a level we feel can be adjusted, then reach to others and build for them. It's a longer path but we feel good about it.

We merged the delegate branch to main - the pattern using delegate objects as interfaces for different environments is working well. Code is complex but the broad approach is solid. Currently debugging a multi-window switching bug.

Arigato gozaimasu!

Packing for a flat move and prepping for trip to Japan slowed us down this week, but we keep pushing to maintain momentum on non coding related tasks.

We dove into exploring what 'modes' Diskura could launch with. Mapped out roughly 50 different potential modes spanning agency work, startup needs, and various use cases, then ranked them to identify what could be core to the product versus nice-to-have features.

This exercise is helping us understand what we can pivot toward and what should be established as fundamental product needs. Since we will bootstrap, we need to be clear on what we can build with our own resources.

We got window splitting working in Electron. This validates that our layout engine can handle real spatial complexity - the foundation we need before building the negotiation engine.

Next up is the negotiation engine itself: a system where components and slots talk to each other about space. Components say "I need this much room" and slots respond "here's what I can give you." It's bidirectional, which will make our platform powerful.

The breakthrough this week came from prototyping in Figma first, using their autolayout to test how properties interact. The video shows the split in action. One layout engine, infinite arrangements, ready for the negotiation layer.

Reorganized codebase into scalable hierarchy - applications to root, clients under applications/client/. Moved Storybook into core app for in-context component development, reducing iteration cycles.

Fixed theming to use global state instead of UI context tied to layouting. Updated all build configs, tests, workflows and infrastructure to align with new architecture. Things feel cleaner.

Defined fundamental component structure covering sizing, position, behavior and visual properties. Split Settings into individual components to establish the component philosophy. Subslot mechanism works well.

Launched Electron desktop version - now supporting both web and desktop clients. Improved layout engine to handle CSS grid control with content alignment and dynamic row sizing.

Built subslot mechanism that enables complex layout fragmentation. Layout engine now supports coordinate variations (A1 vs a1) for size indication.

Cleaned up recursive function issues - DOM output is now clean and manageable. Added GitHub CLI for pull requests and refined the coordinate system philosophy.

This week we had first TV shared coding session - we're truly working as two developers now. Moved layout engine from semantic to coordinate system (A1-B1-B2) and split Settings into 3 components.

This revealed we need component clustering - one more layer for the layout engine. Reached new collaboration level with proper code review workflow.

Implemented first padding fixes and defined the layout engine architecture. Two-tiered system: slots decide grid position, components handle size with flexbox priority.

Restructured Storybook into a catalogue, not a library. Ready for next sprint focused on component development and settings integration.

Got the slots system working with negative and positive space areas. Added design tokens to Storybook and set up Windsurf rules for better AI collaboration. Built a husky script that blocks app areas based on user roles.

Cracked the layout system - modes are working and we can switch between them smoothly. Narrowed down 38 potential features to 5-6 core differentiators for our alpha. Built the first pass of our block editor and writer mode.

Finally working together on the same codebase. Set up Storybook as our project overview and added our first production atom - background.

Backoffice, backend and rest is waiting to be connected with the new UI. Finally have a systematic way to build instead of just exploring. Started building version 2 of the website.

Big milestone this week - we merged magicbinder into the main Diskura project, so we finally have one shared codebase to work on together.

Started designing the 'builder helper' panel, but the real challenge is figuring out how users jump from planning to actually building and back to planning again.

Cracked a major problem: AI gets lost when you give it too much freedom. Built 7-8 guardrails to keep AI focused and prevent it from overcomplicating things when we build Diskura.

This is the difference between AI that helps and AI that creates chaos.

Settled on our system hierarchy: Workspace → Subspace → Project → Builder. Like organizing a craftsman's shop - everything has its place and purpose.

The real challenge: how do you let AI help build while keeping the integrity of the craft intact?

BIG WIN! 🎉 We built our first AI page builder prototype that generates Next.js pages from company descriptions, an early step toward automated design-to-code workflows.

We've also improved our design tool's container performance and added sidebar collapse functionality. The UI is aligning with IDE patterns while we explore interactive canvas concepts.

Automated our deployment pipeline so we can ship updates instantly via github actions. No more manual deployments slowing us down.

Launched our public website to start sharing what we're building. Hello world!

We're taking time to define what a 'project' means in our tool. To us, it's more than a folder of files; it's a dedicated space where fragmented ideas can be thoughtfully joined into a coherent whole.

We've decided to design our user interface directly with code, using AI as an assistant and skip Figma as the main tool. This lets us work with reality sooner, helping us build with a more hands-on, intuitive feel and see what works and doesn't.

The first version of our internal Starter Kit is complete. We see this as building the foundation of our workshop - a solid, reliable base that gives us the stability to build our tools upon.

Our initial roadmap is sketched out. The goal is to address the fragmented nature of modern toolchains by creating a single, shared space where the different stages of creation can come together cohesively.

Craft is often a collaborative effort. We've added user invitations and permissions to the starter kit, making it possible for teams to work together in a shared, organized space.

Switched to a better backoffice tool - Refine. Small changes like this add up - now we can focus on building instead of fighting our tools.

A satisfying moment of 'joinery' this week. The frontend and backend of our starter kit are now connected, turning two separate parts into a single, functioning piece for the first time.

We've refined the core concept for Diskura. The aim is to create an environment where anything that can be coded can be created, with the care and intention of a craftsperson, making it a true partner in creation.

Cut our build time in half with some smart optimizations. As a bootstrapped team, every minute saved is a minute we can spend building features that matter.

While working on the starter kit, we registered diskura.com and started a parallel prototype. This is our space for exploring new UI concepts and asking what a more thoughtful interface for builders might look like.

Decided on RDS Aurora Serverless v2 for our database. Its ability to scale to zero is perfect for low-cost experimentation - a principle that feels important for any creative tool.

Picked a simple state management solution, Zustand and Tanstack Query. We will see how it holds up over time.

Set up a monorepo structure that actually makes sense. No more hunting through scattered folders, everything has a place.

Shipped our first working UI components. They're not pretty, but they work - and that's what matters right now.

Project kickoff. Building feels fragmented - too many tools, too many handoffs, too much context switching. We want to change this with Diskura.

Before we dive into core features we are starting with magicbinder, a starter kit that we can reuse for building anything.