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. I 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.