USER JOURNEYS / LONG READ / 2026
The Year I Started Building Software
About a year ago I wrote an article called UX in the Age of AI.
At the time, I’d already been using AI quite a lot. I used it for research, writing, analysis, generating images and all the other things that had quickly become part of everyday knowledge work.
Towards the end of that article, I encouraged designers to experiment with these new tools, even if we didn’t yet know where they were taking us. Borrowing from Paul Graham, I suggested we should live in the future, then build what’s missing.
I didn’t realise I was about to take my own advice quite so literally 🙂
Over the past year, the way I use AI has evolved a lot. Instead of just using AI to help me do my work, I started using it to build actual software.
And, along the way, a small experiment turned into a real product.
It started with tldraw
I’ve been a fan of tldraw for some time. It has a nice but robust simple canvas, and a great interaction model. You just open it and start drawing.
When tldraw introduced its experimental Make Real feature, which could turn drawings into working interfaces using AI, I thought it was a really cool experiment. But there was something I’d always wished tldraw had: UI components. (I’d even sent them a feedback note on Discord asking for this at some point, to no avail.)
I wanted to be able to drag a button, form field, header, navigation element or other interface component onto the tldraw canvas rather than draw everything freehand.
So, with the help of AI, I decided to try building this myself. I forked the tldraw repo and started experimenting.
Initially I was working with both Replit and ChatGPT and a codebase on my MacBook. I wasn’t ever writing any of the code myself. Instead I was describing what I wanted, getting code back and updating the relevant files in the repo, reviewing what happened, testing it, finding problems and asking AI to change things.
I didn’t regard myself as having suddenly become a software engineer. But equally, I wasn’t just prompting an AI to “make me an app”.
I was working user story by story, making product decisions constantly, e.g. What should happen when you drag a component? How should selection, resizing, etc. work? What belongs in the UI Components picker? Or the Inspector panel? Can I change the default tldraw menus? What should happen when someone deletes a component? etc.
The AI could produce the code, but I still had to decide what the product should be.
Then the tools got much better
I tried a number of AI development tools as they emerged, but the first big leap for me was Cursor.
Suddenly the AI understood much more of the codebase. Instead of generating isolated chunks of code that I had to figure out where to put, it could work across the project, and that changed the pace quite a bit.
Later I moved much of my work to Codex, and eventually I also started using Claude (not the other way round, unlike most!). I used Claude Codex initially, then Claude Code and Claude Design. I’ve used other tools along the way too, including GitHub Copilot and some interesting tools accessible through MCP, including Paper.design.
As the tools improved, my ambition increased with them. Things that initially seemed far too difficult, like creating my own entire tool (instead of just forking tldraw) became plausible.
The experiment became a product
Like I said, my original idea was essentially tldraw plus a set of UI components and an AI “make this real” capability. I even built my own AI assistant into it for a while.
But as the product started evolving, I realised that instead of an “AI drawing tool”, what I actually wanted to build was just a really good web-based wireframing tool.
I’ve used wireframes throughout my career. I still like their deliberate “sketch” nature. With wireframes, it’s easy to design concepts quickly,, and a wireframe gives you enough fidelity to talk about structure, hierarchy, content, flow, and interactions, without prematurely getting bogged down in colour, typography and visual polish.
After many months of building out the interaction design and look-and-feel of this wireframing tool, eventually another fairly significant thing happened – I removed tldraw and recreated my own product from scratch, with its own native canvas editor.
By this stage the AI models and coding tools had improved enough, I had made enough progress with all the necessary product decisions, that building a standalone tool had become feasible. So, with considerable AI assistance, I replaced the original foundation of my original repo. What had begun as a small experiment was now genuinely its own product.
I called it Shape.
And I put it on the internet
Building something locally is one thing. Turning it into a product other people can actually use requires quite a bit more.
There is hosting. Authentication. Databases. Domains. Saving. Sharing. Security. Error handling. Privacy policies. Deployment.
These are all areas that, traditionally, I may not have spent much of my thinking about, and would often have needed somebody else to take care of anyway.
With the help of AI, I ended up deploying Shape using Cloudflare and gradually turned my local experiment into a real web application at shape.ink.
It now has saved projects, a scratchpad for quick throwaway work, sharing, exports, reusable components, templates and a mobile experience.
When I was preparing to share it publicly, I realised something slightly ridiculous: most people clicking a link on, say, LinkedIn or X, would probably first see it on their phone.
So I built a mobile version too.
Not because I think anybody wants to create a complicated wireframe on a phone. But they might want to open one, make a quick change or simply understand what the product is.
That kind of detail is where building a product becomes very different from building a demo.
The best test is that I use it
Shape is live now and people other than me have used it, which still feels slightly strange.
But in other ways, I’m not surprised because I genuinely use it myself.
Recently we were planning to have some work done on our home. I wanted to explore a few layouts and explain some ideas to the builder, so I opened Shape and drew some options, and he understood what I wanted. (And so did my wife!)
That was a nice moment.
For now, Shape is free. You can create projects without paying anything, and there is also a completely free scratchpad that doesn’t even require the commitment of starting a proper project.
I’m not particularly motivated to monetise it. I already have an income.
At some point, if running it starts costing me meaningful money, perhaps there will be paid features for heavier users, if there ever are any such users. But the fact that anybody (in principle) can build and operate a reasonably sophisticated piece of software as a side project raises some interesting questions about where software economics might be heading.
There will be a lot more software. There may be more supply than demand. Software may become commoditised. Who knows?
BTW, I haven’t stopped building Shape
In fact, since releasing Shape.ink I’ve probably accelerated.
The original Shape is deliberately low fidelity.
But increasingly I’ve been thinking about my own design workflow.
I typically want to start low-fi: I want boxes, text, buttons and screens. I want to think about the problem before I worry about visual design.
Eventually, usually after a lot of iteration and feedback, I may want to move into high fidelity. Today that usually means leaving the wireframing tools like Balsamiq and moving the design into something like Figma. (Or trying to do the wireframing in Figma – which is difficult because you always end up gravitating to high fidelity in Figma.)
So I started wondering: What if the same tool could do both, lowfi and hifi work?
That’s what I’m working on now, i.e. Shape is gaining a hi-fi mode alongside its existing lo-fi mode.
I’m not trying to reproduce everything modern Figma or Sketch can do. That would defeat the purpose.
The idea is closer to the simplicity of earlier design tools: frames, components, typography, colour, layout and the things you need to produce a polished interface, without immediately exposing every advanced capability imaginable.
Some people might only use the lo-fi mode. Some might only use hi-fi.
Others, like me, might start with a rough wireframe, turn it into a clickable prototype, gradually increase its fidelity and eventually produce a finished design. That’s what I’m working on now, and it’s nearly done.
And the next step I want is a good hand-off to Figma. Figma has an enormous ecosystem and sophisticated capabilities that I have no interest in recreating.
I’d rather try to bridge the gap. I’m not sure if it will work but it’s an interesting experiment.
Building teaches you things that designing doesn’t
I’ve worked in technology and design/UX since the 1990s.
I’ve worked closely with excellent developers and product managers. When I ran my own consultancy, freelance developers and designers worked for me and alongside me. I’ve led projects from beginning to end. Today I work in a large software product organisation. Software, as I often say, is a team sport.
But there is still something different about building something entirely by yourself. You learn by doing. When there is nobody else to hand the problem to, you start seeing product development differently.
The industry skills are shifting towards deciding what to build, understanding why, directing the tools effectively, recognising when the result is wrong, and having enough judgement to keep iterating until it is right.
The bottleneck has moved
And that leads to perhaps the biggest lesson I’ve learned.
With AI, I can make software much faster than I can properly evaluate it.
That sounds obvious, but I’m not sure we’ve fully absorbed the implications.I can add three new features in an evening.
But I can’t necessarily meaningfully use, let alone just test, those three features properly in an evening.
I need to come back the next evening. Try them again. Use them on a real personal design project. Discover what doesn’t work well, and any other rough edges, including any thing that broke or regressed while fixing something unrelated.
In software, we’ve always talked about dogfooding your own product. I think that becomes even more important when AI dramatically increases the speed at which we can create things.
The bottleneck isn’t building any more – it’s owning the quality.
That last 10% matters enormously, and it hasn’t become 10 times faster just because the first 90% has.
Maybe it never will.
An unexpected observation
There’s something else slightly personal about this whole experience. I’m “making things” more than I have in years. And I’m loving it.
There is an extraordinary feeling of power, creative power, in being able to have an idea and immediately start turning it into something real.
Last year I wrote that this wasn’t the end of UX, but the beginning of a new chapter for designers. A year later, I believe that even more strongly.