Data turns out to be the most important part of the whole project, and the part I understand least. The whole thing is data, so what matters now is how it's managed as it moves through the system, over and over, especially once the learning mechanisms are looping information back through themselves. The data work sits parallel to the mesh rather than underneath it, and it builds straight on last month's hardware work, the CPU and how a machine runs.

What surprised me is that data feels less defined than everything else I've looked at. Less structured, fewer fixed rules. I can't tell yet whether that's because I'm new to it and reading it wrong, or whether it's genuinely true of the area. The hierarchy of terms is hard to hold together, so I'm not making big decisions until I understand the technical limits better. My instinct is decent, but I can't see the blind spots yet, and that's what this phase is for.

If a bit is the atom of data, then I'm trying to solve for the cell, something with a membrane and an inside that holds a purpose rather than just a value.

Not much else got built, because I've been sick most of the week and still am. Victor was home just long enough between trips to drop off whatever he caught, two days before flying out again for a talk, and it landed right in the window where my new flu jab hadn't kicked in. It's one of those colds that grips you and escalates without ever turning into a fever, so there's no real temperature, just everything a bit out of whack.

On the bright side, the consultancy work running alongside the build is going well right now. We're using it to build the financial infrastructure the project needs, the connections, resources and base it can draw on later. It's a deliberate choice, because this is a long, future-facing bet, and AI is pushing projects to be more ambitious and aim at harder outcomes, so building that foundation in parallel feels like the right way to run it. After years of preparing for this, it's becoming real.

I've started seriously questioning whether apps should exist at all.

An app is a container we inherited from how the stack is built. With an app, the maker holds everything and you just use it. With a platform you get to build, but inside someone else's rules, and whatever you make still ships as its own separate app. With an engine or a builder you make the thing, but it detaches and leaves as its own object. Every rung hands the authority to someone else, and the output always ends up as a separate, finished thing you step out of.

What I'm building breaks that ladder. It lets you build something and be inside it at the same time, and it hands that authority to the person using it, to move up and down the stack themselves instead of being locked to one rung. Once that's true, the app as a unit stops making sense. There's nothing to ship out and step away from.

I tried to name it and came up empty, which told me something. It's a platform and an environment at once, maybe a framework too, and every existing word only covers one part. A browser browses. A game engine builds a world but ships a separate game. App builders build, but the output leaves as its own app. Building something and being inside it at once is the thing none of them name. That's why it's a new category, not a new product.

To get there I've been back at the fundamentals of how computers work, down to how a machine goes from power on to a running program. It's pointed me toward placing this above the operating system as its own detached engine, separate from any product, something a whole generation of apps, or whatever replaces them, could be built on. Sitting at that layer, I even find myself wondering what happens to operating systems, whether they end up as something more like terminals.

I spent a stretch zoomed all the way out, trying to place what I'm building on a longer arc. I ended up mapping four eras of how technology evolves in form: fixed, then malleable, then morphable, then evolvable. Each is a real leap, and seeing them laid out made it much clearer where this project sits and how far it can still go. A month ago I couldn't have told you that.

It also settled something about myself. I'm not a product builder who happens to write architecture docs. I'm an architect of a category, using a product to prove the theory. Small thing to write down, but it changed how I hold the whole project.

Then the milestone I've been walking toward for four months: the mapping is done. The last systems went in, the picture of how everything relates finally closed, and I've drawn a line under this phase. I opened a new branch and started the refactor, moving the whole mechanism down into a lower-level language.

This is a different kind of hard. I understand the system I've spent months mapping, and now I'm a beginner again, learning the actual fundamentals of how software sits on hardware, because I can't make good decisions here without them. Every phase has dropped me into a new room of people who know things I don't. I expect this one to be the same, and I think it's where I finally land somewhere concrete.

I've noticed lately that it's getting harder to work in long stretches.

Building a genuinely morphable system means holding a lot of new concepts, terminology and relationships in my head at once, and the cognitive load is getting heavy. I'm learning to work with that rather than against it.

The systems are now mapped, the pieces are sorted, and the architecture is settled enough to move forward. What comes next is the refactor I mentioned a few weeks ago, where part of the core needs to move into a different language to make morphability work properly.

The stack keeps evolving naturally: TypeScript and React, Clojure where it makes sense, and now I'm looking at a lower-level systems language, the kind of thing C++ or Rust is, for a core that has to bear a heavier computational load than the current stack can handle. Each step feels completely reasonable while I'm in it. Then I zoom out and remember that three years ago I was on Codecademy learning JavaScript, only to give up because the course bored me and I needed something harder to keep me interested.

I don't seem to have much of a middle ground as a person, which may actually be a useful trait for a project like this.

I went back to the drawing board this month and reworked the architecture. I've been calling what I'm building morphable software, which sits close to the malleable software a few others are working on. Malleable means you can reshape a tool. Morphable means the tool can change what kind of tool it is. I'm not that focused on the workspace itself right now, since I think that part will come together later. The technology underneath is where I am, because that has to be right first.

I started looking at separating the core from the UI code, so the workspace can exist as a model that runs without being drawn on a screen, and the interface hooks onto it afterwards. I'm testing Rust and Clojure for that layer and borrowing some ideas from how financial systems are built. So far it looks like it could work.

I also kept mapping out the systems, filling in missing ones and merging a few that turned out to belong together. I want the whole thing to reach a kind of equilibrium on paper before I write any code for it. The newer pieces cover how a workspace stays consistent across devices, how much it can change without starting over, and how two people can work in it without one of them having to work the other's way.

One line came out of this that I like. People using the same workspace aren't looking at the same screen. They're working through different expressions of the same underlying thing. That's what the technology underneath should make possible. It's the clearest I've managed to say it.

The build hasn't had my full attention lately. A new landlord took over our building and within a month wrapped it in opaque advertising that blocks the view and put prices up 10%. Fighting that has taken a lot of time and energy. Buying somewhere is exactly what I wanted to avoid for now, so I could keep money and flexibility for the business, but housing here is unpredictable enough that committing might turn out to be the safer option. It's a strange thing to be weighing while trying to build.

Most of the time went into systems, and the thing that actually moved was boundaries: understanding where one system stops and the next one starts. Sounds minor, but it changes how everything gets filed, so I reorganised a chunk of the code to match and started pulling out an older piece a newer system now handles. Added two more systems and split one in half after realising the two sides were doing different jobs.

This is the most complex work I've done so far. The layers are hard to hold in your head at once and progress feels slower than it is.

Had a good chat with Victor about reactive versus proactive software. Diskura will be able to act ahead of the person using it, but the real question isn't whether it can, it's whether people will want to hand over that much control. I don't think the answer is obvious.

London is very hot these days. My flat is over 30C and this kind of work does not go well in that heat. I spent the week reading research and learning new concepts around malleable software. Other people are poking around the same area, each with a different approach, and at some points even their wording matched mine. This makes me happy as it feels 'my people' exist. Interest in the area is a good sign, but it is also a competitive space which stresses me out since I am on the margins of it all. Compared to someone in San Francisco I still feel like a country bumpkin making things in my shed, London or not.

The reading helped me sharpen how I describe what Diskura is and how it differs from the work around it. That distinction stays internal for now.

On the build side I expanded the internal structure: two new systems, one existing one split in two, and a clearer picture of which parts belong together. Representing that in code is next.

Back in London after a lot of travel. The trips were good but I'm glad to be home and done moving around for a bit. The next couple of months are about settling in and getting through the heavy work.

Had a good chat with an investor I've known for a while. The feedback on where I'm heading was positive, which was nice to hear and pretty motivating going into a busy stretch. Good to know I'm in the right rooms.

I'm still nervous about investment though. A project like this needs financial backing at some point, and I know that, but entering that arena genuinely worries me. So many businesses these days seem built around one approach, and often it's about quick turnarounds rather than a long game to actually win the market. What I'm building feels like it needs years of patient work and community around it, on something that's trying to shift how software works. I see both sides and I honestly don't know which is right. For now I'm ok parking that worry and focusing on what's in front of me. I'm lucky to have the time to build something this big on my own funds, but I know a decision will come eventually.

Did a lot of reading this week, most of it circling the space Diskura sits in. Morphogenesis, which is how a single genome builds a whole organism through context. Neural cellular automata and generating structure from almost nothing with machine learning. MAPE-K loops and self-adaptive systems that sense what's around them and adjust on their own. Different fields, but they all point at the same idea I keep coming back to: software that grows and adapts to its context rather than staying fixed. Good to see serious research pushing in that direction.

On the system, more mapping and cleanup. I spent a good while on one of the harder problems and the shape of a better approach started to come through. Also tidied up docs and loose ends so it's cleaner for the next phase.

Updated the website with a new layout and design. It feels more put together, and the storytelling and design language are starting to come through.

Most of the week went into working out how to explain what Diskura is and where it sits relative to other software. The copy kept falling flat while building the site, so I focused on the positioning itself and came out with a clearer sense of it. Still early, though further along than before.

The pipeline got more attention too, mapping out how a single action moves through the system step by step. That work uncovered missing pieces in request / absorb phase and let me refactor some of the underlying code. Going through the whole diagram and adjusting the code as I build the system out will probably take a couple of months, and I'm mentally preparing for it because it's tedious. The product is genuinely complex, which is what makes the challenge interesting, and the work feels worth it. A few more pieces are now queued up for next.

A patchy stretch but catching stride. Got properly sick at the start, then London hit a 35°C heatwave, then off to Scotland for Vic's 40th. Tempo dropped but didn't disappear, which I'll take.

Most of the real work went into a pipeline-flow diagram, mapping how a request actually moves through the system. Picked three request types that will stretch things, and started a heavier breakdown of the first one: activating a feature inside an existing feature and adapting the workspace layout to support it. Even this early, the diagram is uncovering a lot of what's missing.

That mapping surfaced a missing piece: where decisions and intent actually live, shaping how a request gets handled and making calls for the system and the user when needed. Also started thinking properly about memory, state and how things stay in sync over time. Built up a vocabulary so I can actually reason about each piece.

A lot of this is above my paygrade. I'm designing things I don't fully know yet, leaning on transferable skills to make decent guesses and studying as I go. It's slow but fun, and I'm understanding state, store, sync and signals a lot better than I did a month ago.

I built a model of how the whole system fits together - the moving parts and how they relate, with a clear structure on top for how decisions and control flow between them. Leaned into a NASA/mission metaphor as the backbone to help me understand what's 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 big rebuild I've been grinding on for weeks. One clean runtime now across web, desktop and mobile, with proper boundaries and fast feedback while I work. Felt good to ship something concrete after weeks of audit work.

Pulled the trickiest space-and-behaviour logic into its own home. 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. Cleaner seams, less accidental coupling.

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 I'm doing it: I'm restructuring how the system thinks about its own work. Instead of one big undifferentiated blob, there's now a clear lifecycle - distinct stages from the moment something enters the system to when it's delivered. It's a structural 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. Separating each stage should give me much more control.

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

Now rebuilding the architecture from the ground up to be cleaner and more flexible. 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 a similar approach, which made it feel less crazy. Small validations like that matter when you're doing an unconventional 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.

Moved over some of the bigger, core 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, I 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 I'm resilient and there is always a way.

TypeScript and React are hitting their limits for what I'm 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 me a lot - archived it as a learning pass. The next rebuild should be cleaner now that I 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 I 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 my tooling to Biome and did a full project reorganization. Upgraded to React 19 and the latest React Native versions - I was 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 I'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 my 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 my 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 my 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. I can see the path forward more clearly now.

Got modes switching cleanly - the video shows it in action. The whole point is that behaviour, not just layout, can be reused and recombined.

Reorganised the entire system so components, behaviours and flows live in one consistent structure, with a single entry point instead of updating each platform by hand.

The architecture is starting to look really coherent, and I understand the fundamentals much better now - including how to work with AI to speed things up. This should make building actual products much faster and more efficient.

Started mapping out the whole app as a single connected picture, and got clearer on what a "mode" really is: a set of intent-based actions that produce consistent output. Built a simple counter as my first real test of the idea. I'm replacing how pages work with self-contained pieces that can be recombined, so I can build anything without duplicating work.

Started on deeper nested layouts but hit some hard edges and parked it for now. Added native parity, reorganised things, and set up a single entry point. Pushed the simplified direction into main - I'm committed to this approach now.

Separated the validation rules from the space-sharing logic so they can run independently. The fundamental rules now hold on their own.

Started preparing components before turning the space-sharing behaviour on for them. The bigger challenge now: getting modes comprehensive enough to replace pages and routes entirely, if possible.

Rebuilt the layout foundation so it's predictable enough for AI to generate against. The space-sharing logic had gotten too complex and unstable, so I reverted to a clean version and added clearer rules for how nested elements size themselves. Some are solid; others will surface bugs.

Exploring stacked tooling across multiple viewports. Vic is building 'foundation' - an AI compliance platform on the same foundation as Diskura. 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 the core system runs on every platform - web, desktop, mobile, all working. Built the part that decides how things rearrange when space gets tight: what stays, what gives, what hides. Added tests so the behaviour is reliable, not lucky.

Multiple viewports within a window, working across all platforms.

Also wrote a Product Vision doc that finally made the bigger structure click for me - how the foundation, the product, and the things built on top all relate. Having that clear lets me build systematically instead of by feel.

Stripped down to a minimal MVP to focus on the hardest piece - how elements share space with each other. Just 2 modes and 2 components, kept on a clean branch.

Started building mobile support with Expo alongside web and desktop. Good choice to start with as there were conflicts early on. Better to mitigate them now.

Refactored the platform and moved the core into place 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.

I've been chipping away at small updates where I 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.

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

I got window splitting working in Electron. This validates that the core system can handle real spatial complexity - the foundation I need before the next hard part.

That next part is the trickiest one: getting elements to share space intelligently when there isn't enough to go around. It's what'll make the whole thing feel alive rather than rigid, and it's the piece I'm most excited (and nervous) to get right.

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 system, endless arrangements - and the hard part still ahead.

Reorganized the codebase into a cleaner, more scalable structure, and moved the component workshop in-context so iterating on UI is faster.

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 a clear structure for what a component is - sizing, position, behaviour, visuals. Split Settings into individual components to establish the philosophy. The nested-space approach is working well.

Launched the Electron desktop version - now supporting both web and desktop clients. Improved the layout handling for finer control over alignment and dynamic sizing.

Built the mechanism that lets layouts break down into finer, nested pieces - the foundation for more complex arrangements.

Cleaned up some gnarly recursive issues - the output is clean and manageable now. Added GitHub CLI for pull requests and kept refining how the spatial side works.

This week we had our first TV shared coding session - we're truly working as two developers now. Reworked the layout to a more spatial, grid-like approach and split Settings into 3 components.

This revealed we need a way to group components together - one more piece to figure out. Reached a new collaboration level with a proper code review workflow.

Implemented the first spacing fixes and defined how the layout works at a structural level - a clear split between what decides position and what decides size.

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

Got the spatial system working with both filled and empty areas. Added design tokens to Storybook and set up rules for better AI collaboration. Built a script that gates parts of the app based on user roles.

Cracked the layout system - modes are working and I can switch between them smoothly. Narrowed down 38 potential features to 5-6 core differentiators for the alpha. Built the first pass of the 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 I build Diskura.

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

Settled on my 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! 🎉 I built my first AI page builder prototype that generates Next.js pages from company descriptions, an early step toward automated design-to-code workflows.

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

Automated my deployment pipeline so I can ship updates instantly via github actions. No more manual deployments slowing me down.

Launched my public website to start sharing what I'm building. Hello world!

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

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

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

My 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 I can focus on building instead of fighting my tools.

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

I'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 my build time in half with some smart optimizations. Bootstrapping solo, every minute saved is a minute I can spend building features that matter.

While working on the starter kit, I registered diskura.com and started a parallel prototype. This is my 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 my 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. I'll 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 my 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. I want to change this with Diskura.

Before I dive into core features I'm starting with magicbinder, a starter kit that I can reuse for building anything.