115.local
115.local / Local AI, household systems
A private system that lets the house answer for itself.
115.local is a private site I run on my apartment’s local network. It gives everyone in the house one place for our calendar, bills, documents, local information, and Frankie, a Qwen-based AI that runs locally through Ollama.
The project started when I realized I already knew how to make all of the individual parts. I knew how to build websites, I knew how to run one across a local network, and I had been experimenting with local language models. My roommates were also regularly running into the same problems around utilities and shared information, so I wanted to see what would happen if I combined all of it.
I’m Frankie. Ashton and I are going to walk you through this together. I’ll be down in the bottom-right corner the whole time, so open me whenever you want to hear more about wherever you’ve scrolled to.
The home screen
Frankie is available at all times through the button in the bottom-right corner, but I did not want the whole thing to become a chatbot. The calendar, library, tools, private roommate section and basic house information all still have their own place, with each area colour-coded so it is easy to recognize.
115
- OCT 156:30 PMHouse dinnerKitchen
- OCT 20All dayGuest visiting for the weekend
- OCT 24All dayA. away until Thursday
Sanitized recreation · network name, password and events are placeholder values · nothing behind Keep Out is shown
01 / The premise
What if the house remembered the things we kept asking each other?
Most household questions are not difficult questions. Someone knows when the gas bill was paid. Someone knows where the extra towels are. Someone has the appliance manual. Someone remembers which grocery store opens earliest.
The problem is usually figuring out who knows, where they put it, and whether they are around to answer.
115.local started as an experiment to put more of that information in one place and make it available to everyone on the apartment’s network. Frankie made it possible to ask for the information normally instead of having to know where on the site it was stored.
02 / Building the system
The AI was there from the beginning. The calendar worked first.
Frankie was part of the idea from the start, but the first thing I actually got working was the calendar. After that came Frankie’s knowledge base, then documents and files, then the conversation history and context work that made Frankie considerably more useful.
Other tools got added when there was an actual reason for someone in the apartment to use them.
01 — Calendar
Shared time came first.
The calendar was the first finished part of 115.local, and we still use it for group plans, guests, and letting everyone know when somebody will be away.
It eventually grew past a basic calendar. Events can have locations, recurring schedules, RSVPs and discussion, and I added support for less convenient repeating dates when the normal weekly and monthly options were not enough.
Event detail carries recurrence, location, RSVP states and an attendee roster, so the calendar reads as a shared household record rather than a demo widget.
02 — Frankie + Knowledge
Then there was someone to ask.
Frankie sits in the bottom-right corner throughout 115.local, so asking him something does not mean leaving whatever part of the site you are already using.
His household knowledge is also separate from the model’s general knowledge. Information we have specifically entered about the apartment takes priority when it applies; otherwise Qwen can still answer normal questions from its own knowledge.
That distinction became much more important once I started testing how much context I could give him.
The Frankie button is fixed in the bottom-right corner across the whole system. Answers carry their sources, and house-authored facts outrank the model’s general knowledge.
03 — Library
Some answers live in files, not fields.
Documents came next because not everything worth remembering fits neatly into a database field. 115.local can pull information from PDFs, Word documents, spreadsheets and other files into the same system Frankie uses.
Uploads are reviewed before becoming shared documents. I also separated documents people should be able to browse from documents that exist only as context for Frankie. Something can be useful to the AI without needing to sit visibly in the household library.
Uploads are moderated (note the pending row), and there is a document of house notes only Frankie can access, as part of his additional context.
04 — Bills
One of the boring parts became one of the most used.
The bills section replaced utility information that had been scattered across texts, individual accounts and people’s memory with one shared record.
Both of my roommates now use it regularly. I can see that in the growing history of bills and household spending, which is probably better evidence that the feature works than anything I could say about it here.
Real amounts, account numbers and names are never shown. The point is the shared record and its steady use, not the figures.
Frankie
Frankie was already here.
Frankie was the apartment mascot before he was an AI. He had already appeared on our whiteboard, in a painting, and as a ridiculous 3D-printed figure wearing a top hat, sunglasses and a sardine shirt.
So when I needed a personality for the household AI, there was not much of a naming process. Frankie was already the obvious answer.
03 / AI behavior
Getting a model to answer was easier than getting it to answer the right question.
I got a local model answering questions fairly quickly. Getting it to behave like it actually understood a household took much longer.
At first, every message was being interpreted too independently. A follow-up question could lose the conversation immediately before it, so I added persistent chat history and started passing more of the conversation back into the model with each request.
That helped, but then Frankie started doing something stranger: he often had the correct answer and still had no idea which information was relevant.
Early behavior
“Where is the fire extinguisher?”
He might tell you correctly.Then recommend a nearby bar.
Summarized from early testing, not a verbatim transcript
Early behavior
Information to remember for the gas bill
He might confirm it.Then volunteer that another roommate owned a 3D printer, and offer his phone number.
Summarized example, no real personal information stored or shown
More context was not automatically better context.
At that point the problem was no longer getting information into the model. Frankie already knew plenty. I needed to control which information reached him, what took priority, and what belonged in the answer.
I went through repeated changes to the prompts, knowledge-base structure, source hierarchy and conversation history. Household facts were separated more deliberately from general knowledge, and the context sent with each question became more selective.
That was probably the biggest breakthrough in the project. Frankie became useful once he stopped trying to prove how much he knew.
What Frankie sees before he answers.
A question can pull from several parts of 115.local: house knowledge, documents, bills, the calendar, the current user’s access level and the conversation so far. The Home Hub layer decides what applies before the request is sent to Qwen.
The model is only one part of the system. Most of the work was deciding what to give it.
How a request becomes a relevant answer
Architectural view. Specific backend function names are left out until confirmed against the current code.
04 / Why I kept it local
I did not want the house to depend on an AI subscription.
I could have sent Frankie’s questions through a commercial AI API, but there was not much reason to. Qwen runs well enough locally for what I need, there is no per-message API cost, and household information does not need to be sent to an outside AI service every time somebody asks a question.
Users also never communicate directly with Ollama. They use 115.local, and the WordPress and Home Hub layer decides what information and context gets sent to the model.
The same thinking carries through the document system and private areas. Running the model locally does not automatically make the system private; permissions, file handling and what each user is allowed to see still had to be designed separately.
- Application
- WordPressCustom theme
- System layer
- Home HubCustom plugin
- Interface
- PHP / JS / CSS
- Model runtime
- Ollama
- Model
- QwenRunning locally
- Environment
- LocalWPHousehold LAN
- Access model
- Private, local-network first
Building past what I already knew.
I used AI coding tools throughout the project, particularly as I moved further into PHP, WordPress internals, local-model integration and debugging.
I still decided what the system needed to do, how the information should be structured, what the interface should look like and how Frankie should behave. AI mostly let me build further into the technical side of those decisions without needing another person to implement them for me.
05 / In use
The best test came from a guest who woke up too early.
A friend stayed over for a weekend and woke up hours before anyone else. He needed a towel, so he asked Frankie where the extras were. Then he wanted to go grocery shopping and asked what was nearby.
By the time the rest of us woke up, he had gotten ready and gone shopping without needing to ask anybody anything.
It was a very ordinary use of the system, which is probably why it made the point so clearly. Those were exactly the kinds of questions that would normally require finding whoever happened to know the answer.
- Bills
- Both roommates routinely use the shared bill and spending records.
- Calendar
- Group plans, guest visits and time away from the house are regularly added.
- Frankie
- Household questions get answered without first knowing where the information lives.
06 / Next
Two things I still want the house to control.
115.local is still changing as we use it. The two integrations I want to tackle next are both things already inside the apartment that currently require separate software.
3D printing
I want to be able to send a file to the household 3D printer through 115.local, or at least put it into a queue to be printed later.
Smart lighting
I also want shared lights to be controllable from the site. Requiring every roommate or guest to download the manufacturer’s app just to adjust a light feels unnecessary when there is already a local interface everyone can use.
07 / What it led to
Other people wanted one.
115.local did not start as a business idea. I built it because I realized I could and wanted to see whether it would actually be useful.
After I showed it to my dad, his immediate reaction was that he wanted one for his house. His household has more people, more schedules and more caregiving responsibilities than mine, and many of the same small information problems happen there at a larger scale.
That was the first time I seriously considered the system outside my own apartment. It eventually led to Hestia / Loci, where I started exploring how a related product could work for other homes and spaces without simply copying 115.local.
115.local is still running in my apartment, and I still change it whenever using it exposes something annoying.
A strange Frankie answer becomes another context or prompt change. A question that keeps coming up can become a new piece of house knowledge or a new feature. The bills and calendar keep accumulating real use, which gives me a much better idea of what deserves work next than treating the project as finished would.
Personal project / 2026–present