Why I'm Building Lyre

I started building Lyre because I wanted to use the apps I was making.

Claude Code and Codex became part of how I worked. I could ask for a change, follow the conversation and see the code taking shape. But when I was away from my desk, I kept running into the same problem: I wanted to pick up my phone and actually try what I had built.

Reading that a change is finished isn't the same as using it. I want to tap the button, fill out the form and see whether the whole thing makes sense on a small screen.

The loop I wanted

Depending on the project, testing meant setting up a demo server, configuring another service or preparing a build. Then I'd notice something small, ask for a change and go through the process again. Sometimes I was spending more time getting back into the app than deciding what to improve.

I wanted a shorter loop. My computer runs the project. I open an interactive preview on my phone, try the change and keep working wherever I am.

That's the core idea behind Lyre. For supported projects, changes that work with live updates shouldn't need a new distribution build just so I can try them. Some native changes still need a rebuild. I want the everyday testing process to take fewer steps.

I have more than one computer

My work is spread across a Mac and Windows computers. Different projects and tools live on different machines, and the computer in front of me isn't always the one doing the work.

I want to see what each machine is running, read its agent conversations and know when something needs my attention. I don't want to set up a separate way of checking on every computer.

For a future release, I'm planning a view of all your own hosts and their workspaces under one account. Each desktop should be able to host its projects and act as a client of the others. If the same repository is on two computers, those copies should appear together with clear labels showing where each one runs.

I'd also like to hand a task from one computer to another without having to explain everything again. That's future work, including making sure the destination has the right files, tools and permissions.

And sometimes there's another person

Think about two teammates working on the same app. Both ask an agent to fix something, but neither knows what the other has started. They can end up doing the same work and only discover it when they compare their changes.

I want Lyre to help people see that work earlier. What is your teammate trying to do? What is their agent doing? Which computer owns the task you're waiting on?

Shared workflow visibility and coordination across hosts are part of the longer-term plan. The point is to help people divide work and keep track of it while it's happening. Permissions, task ownership and recovery all need to be clear before that becomes something teams can rely on.

Some apps only need a few users

A useful app doesn't have to become a public product. It might be a tool for your business, something your family uses or a small project that solves a problem only you have.

I imagine a lot of people would rather use what they've made than figure out an app-store launch. I want Lyre to make supported apps easier to access through a preview while their creators keep the code and continue improving it.

This matters for entrepreneurs too. Before investing in a launch, you might want five people to try an idea. Let them use it, find out where they get stuck and make changes while their feedback is fresh.

A simple user code is on my future roadmap: give someone a short code, let them enter it and take them into the shared app without developer onboarding. I also want testing feedback to connect with errors and diagnostics, so you're not left guessing what happened on someone else's device. These are planned additions, not finished features.

Keep the project on your computer

Local ownership is a big part of why I'm making this. In Lyre's host-based preview flow, your computer runs the project and your phone connects to it. When a relay is needed, it carries the connection rather than hosting a public deployment of your app. Your host still needs to be awake and online.

That doesn't mean every part of development stays local automatically. If you choose a cloud AI provider, the context you send it goes to that provider. Accounts and other connected services have their own data flows. I want those choices to stay understandable.

I want room for local models

I think local models are going to matter a lot. Some people will choose them for privacy, some for cost and some because they want more control over their setup.

I want Lyre to work across models and providers as supported integrations grow. Changing the model helping you shouldn't mean abandoning your projects or learning a completely different workflow.

That's what ties all of this together for me. I want to know what my computers are doing, work alongside other people and use the apps we're making. I want to be able to make a change on the go and see whether it actually helped.

There's still plenty to build. I'll use this blog to share what I'm learning as I go.