micasa: a modal terminal app for the maintenance of your own house

The five questions it is built around

micasa is a modal TUI for tracking home projects, maintenance schedules, appliances and vendor quotes, and the feature list is written as five questions a homeowner actually asks.

The first is when did I last change the furnace filter, and the answer is schedules, due dates and full history, with the promise that you set it and forget it. That is the maintenance scheduler, and the full history part matters more than the reminder part, because the reminder is only useful if you can see what happened last time and what you paid.

The second is what if we finally did the backyard, which is the project tracker, and the answer is projects from napkin sketch to completion, or graceful abandonment. That last phrase is a design position. A project tracker that only models success makes you abandon the project in the data rather than in reality, and the record of an abandoned project is often the more useful one.

The third is how much would it cost to, which is the quote and cost side, and the answer is quotes side by side, vendor history, and the math to actually decide. Side by side quotes from different vendors for the same job, with the history of what that vendor charged last time.

The fourth is who did we use last time, which is the contractor and job history, and everything is searchable: every contractor, every quote, every job.

The fifth is how much have I spent on plumbing this year, and the answer is ask a local LLM, or don't, and the key word is offline until you say otherwise.

That last one deserves attention because it is the only feature with a privacy dimension. The framing is that the model runs locally, and the default state is that nothing leaves the machine until you opt in. The dependency list backs that up with `github.com/mozilla-ai/any-llm-go`, which is a provider-agnostic interface rather than a hard dependency on one hosted service.

The application is written in Go, the licence is Apache-2.0, and the last push was on 2026-10-15 with version 2.8.0 released on 2026-04-26.

Modal keys, and a design lineage you can name

The interface is keyboard driven with Vim-style modal keys, with a `nav` mode to browse and an `edit` mode to change things. You can sort by any column, jump to columns with fuzzy search, hide what you do not need, and drill into related records. There is a full keybinding reference in the documentation.

Modal design in a terminal application is a real design decision, not a keyboard shortcut gimmick, and it has consequences. A modal interface makes the arrow keys available for navigation rather than for text editing, which matters in a data browser where you are mostly moving around a grid. It also means the key space is much larger, because a single key means different things in different modes, and the cost is a learning curve that the reference documentation exists to cover.

The lineage is stated directly: the TUI design is inspired by VisiData. That is worth knowing because VisiData is a terminal data browser, a spreadsheet interface over arbitrary tabular data, and it is a different kind of program from a to-do list. Borrowing its interaction model means micasa treats a household as a database to be explored rather than a checklist to be worked through. Hiding columns, sorting by any of them, and drilling from a job into the contractor who did it are all spreadsheet operations.

The implementation follows the same idea. The dependency list is the Charmbracelet stack, with bubbletea for the event loop, bubbles for the components, lipgloss for the styling, glamour for rendering Markdown in the terminal, huh for the form and confirm prompts, and fang for the command line. There is also `bubblezone` for mouse-aware regions and `charmbracelet/x/ansi` for colour handling.

Two additions to the stack are worth noting. `github.com/itchyny/gojq` is a Go implementation of the jq query language, which suggests the data can be queried with a jq-style expression rather than only through the interface. And `github.com/mark3labs/mcp-go` is an MCP server library, which is how the application exposes its records to an AI agent rather than only to a human at a terminal.

The `fang` dependency is the command line front end, and it is worth a note because it is what makes the same binary present well in a terminal with colours, help and errors rendered properly, which is the difference between a tool that feels native and one that feels like a script.

One binary, a local database, and no CGO

The project is Pure Go with zero CGO, which is a bigger constraint than it sounds and explains most of the other choices.

CGO is the mechanism by which a Go program calls into C code. Avoiding it means the resulting binary is genuinely static, which is why the Dockerfile is this short:

FROM scratch
ARG TARGETPLATFORM
COPY $TARGETPLATFORM/micasa /bin/micasa
ENTRYPOINT ["/bin/micasa"]

A `FROM scratch` image contains nothing but your binary. There is no libc, no shell, no package manager and no operating system underneath, so the container is the program and nothing else. That is a genuinely small image, and it is also a claim about supply chain surface, since there is no system library to patch.

The cost of zero CGO is the database driver. The C SQLite driver requires CGO, so this project uses `modernc.org/sqlite`, a pure Go translation of SQLite, and the repository carries a `LICENSE-glebarez-sqlite` file. The database layer is GORM, with `gorm.io/driver/postgres` also in the dependency list, so the schema layer is not tied to SQLite alone.

The storage design is a set of small libraries that each do one thing. `adrg/xdg` handles the platform's standard config and data directories. `oklog/ulid` gives sortable unique identifiers, which is what a record store wants since ULIDs sort by creation time. `dustin/go-humanize` formats numbers for display, `iancoleman/strcase` converts between naming conventions, and `nyaruka/phonenumbers` handles phone number formatting, which is the kind of domain detail a contractor and quote system needs.

`brianvoe/gofakeit` is the fake data generator, which is what makes the `demo` command and the test fixtures possible. And `tj/go-naturaldate` parses natural language dates, so a due date can be written the way a person would say it rather than in a format the database expects.

`google/shlex` and `spf13/cobra` and `spf13/pflag` are the command line and shell parsing layer.

The data model is the product, and it is broad

The feature list is short, so the shape of the data is best inferred from the dependencies and from the vocabulary used throughout, and it is a household operations database rather than a todo list.

The entities the questions imply are projects, schedules and their due dates, appliances, contractors, quotes and jobs. Each of those has a history, and the history is the point. A quote has a vendor, a price and a date, so the same job can be compared across vendors and across years, which is how the math to actually decide becomes possible. A contractor has a job history, which is how the who did we use last time question gets answered.

The input validation dependency, `go-playground/validator/v10`, is the standard Go struct validation library, and it points at how the records are shaped. A record type with tagged fields, validated on the way in, is the natural shape for something that has to survive being entered by hand on a phone or a terminal and queried later.

Two features of the data layer are more than plumbing. `github.com/BurntSushi/toml` handles configuration, and `glamour` renders Markdown in the terminal, which suggests notes fields on records are Markdown, which is a reasonable choice for a contractor invoice or a project description. And the `postgres` driver in the list means the intent is that the same schema can run against a server database if a household needs it, even though the default is a local file.

The `plans/` directory at the top of the repository is worth a mention, and so is `POSTMORTEMS.md`. Both are signs of a project that records its own reasoning and its own mistakes, which is what a maintainer who intends to keep the thing running for years tends to do.

The documentation site is at micasa.dev/docs, and the project homepage is micasa.dev.

How to run it, and the AI feature to read carefully

Installation is one command for anyone with Go installed:

go install github.com/micasa-dev/micasa/cmd/micasa@latest

Or you can grab a binary for Linux, macOS or Windows from the releases page. The release workflow is driven by `.goreleaser.yaml` at the top of the repository, and there is a `VERSION` file, so the version string comes from the repository rather than from a tag convention.

Then the first run, and the two commands are a good way to understand the shape of the thing:

micasa demo         # sample data
micasa              # your house

The demo mode loads sample data so you can see the interface without entering anything, and the second command opens your own empty house. The first one is the one to do first, and it is worth doing because the interface is modal and learning it with data in it is much easier than learning it with an empty database.

The AI feature is the one to read carefully before you use it. The feature list says you can ask a local LLM how much you have spent on plumbing this year, or don't, and it is offline until you say otherwise. The `any-llm-go` dependency is the provider-agnostic layer, so the same code can talk to a local model or a hosted one, which means the privacy property depends on configuration rather than on the code alone.

For development, the project ships a Nix flake, so `nix develop` enters the dev shell, and the tests run with:

go test -shuffle=on ./...

The shuffle flag is a small thing worth copying. It randomises the order of test execution, which catches tests that pass only because of an ordering dependency, and it is cheap insurance in a project with a lot of state.

One more thing to know about how the project is built. The README says it was developed with AI coding agents, Claude and Claude Code, and that pull requests are welcome including AI-assisted ones as long as you have reviewed and curated the code. The repository has `AGENTS.md`, `CLAUDE.md` and a `.claude/` directory, so the agent instructions are part of the source tree, and the security tooling is visible too, with `govulncheck-exclude`, `osv-scanner.toml`, a `codecov.yml` and a `biome.json` alongside the Go linting configuration.

Editorial conclusion

micasa fits a homeowner or a caretaker who has a spreadsheet of maintenance history and wants a real tool instead, because the schedules, due dates and full history are first class and the data stays in a local SQLite file under your control. Skip it if you need a shared household database with several people editing at once, since this is a single user terminal application, and read the AI feature carefully before turning it on, because the local model path is the one thing here that could send your household records somewhere. Before you adopt it, try `micasa demo` with the sample data first, and note the toolchain, since the go directive is 1.27.2 and the project is built with AI coding agents and asks contributors to review and curate what they submit.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. micasa-dev/micasa on GitHub
3. Project website
4. README
5. Releases