The two things I have built and kept running.

What is actually inside each one.

Cross-checking a listening history against a dozen venue calendarsConcerts For You

To find out which of the bands you already listen to are playing near you, you have to open your streaming history in one tab and a dozen venue calendars in another, and then do it all again next month. Nobody keeps that up. People hear about the show the week after it happened. This does it instead. You hand it the listening history you can export from Spotify or YouTube in about a minute. It reads the artist names out of the file and checks what is on sale inside the distance you are actually willing to drive.

What comes back is a deck of shows you go through one card at a time. Each card carries the venue, the date and the real driving distance, and a counter tells you how many are left. The recording at the top of this page is thirteen seconds of that deck, filmed against the live site.

What it runs on: One Node process serving both the browser application and its own API, with SQLite behind it, on a single container. The listening history is read out of the export file you hand it and the shows come from Ticketmaster’s own data, so there is no third-party recommendation service in the middle deciding what you are shown.
What it costs to run: It shares that container and that database file with Wedding 2027. Those are my two products, not anybody else’s, so the two of them together are one hosting plan and one domain rather than one bill each. What I would build you is that same shape on the platform I run this business on: one deployment I patch in one place, your own domain in front of it, and your data kept to itself, separated from mine and from anybody else’s. That data comes back to you in a named format whenever you ask for it. The reason that shape is the cheap one to keep alive is in the band under this one.

Open Concerts For You at delaneymizell.com/concertsforyou, in a new tab

A four-country deposit schedule, kept in one placeWedding 2027

The Wedding 2027 itinerary on screen, with example amounts standing in for the real ones. A masthead reads Wedding 2027, Mizell and Boyd, above a line giving the dates, May 2027 to July 2027, and four chapters, and the heading The Journey, beside a map of the route across Europe and Asia. A row of buttons reads Italy, Vietnam, China, Japan, then countries, cities and days, with days selected. To the right of them sit three totals: a total cost, nothing paid so far at 0 percent, and the whole of that cost still owed. A banner says nothing has been booked yet, anywhere on this trip, and that nothing has been paid for either. Below it the Italy chapter runs May 15 to 23, split into Positano and the Tuscan countryside, each day a column of cards: land at Naples, lunch at Da Adolfo, the ceremony on the terrace. Every card is stamped NOT BOOKED and carries its own estimate, unpaid.

A wedding trip through four countries is a spreadsheet of deposits, a folder of confirmation emails, and a text thread where somebody asks which villa has to be paid by Friday. Three places to look, and none of them agree with each other. I built the site that holds the whole thing in one: the itinerary day by day, the money sitting against each line, the papers, and the mail from the vendors.

The page opens with the trip: four chapters, city by city, and under each city the days, with their events down the page and an estimate against every one. Nothing on it is booked and nothing is paid for. It says so plainly above the first day, and every row carries a NOT BOOKED stamp until somebody says otherwise. That is the state a trip is actually in for most of the year it is being planned. Holding it honestly, with the estimate and the confirmation as two different things on the screen, is what the spreadsheet and the folder of emails could never do between them.

What it runs on: The same process, the same SQLite file, the same container as Concerts For You. It is a second surface on one deployment rather than a second deployment.
What it costs to run: Nothing beyond the plan the first one was already paying for. That is what one deployment means.

Open Wedding 2027 at delaneymizell.com/wedding2027, in a new tab

Both of them are one deployment, and that is deliberate.

Two products on two servers is two of everything: two sets of security patches, two dependency bumps, two migrations, and two places to look when something is quietly broken over the weekend. One person cannot keep that honest for long, so I do not build it that way. One container, one database file, one deploy, one place where the logs are.

This matters to you as much as to me, because your software would be the same shape. The cost of keeping a small piece of software alive is almost entirely the cost of the attention it needs. That arrangement is the one that needs the least of it.

What would you like to make easier?

Tell me about the job your team keeps doing by hand. We can work out where software would help.

Call me 919-909-0806 Email me Fill out the form