Journal · Studio

Why StatikNet exists

I started by shipping software under my own name. A studio gives the work a steadier home. Here is what StatikNet is for, and what it won't become.

For a while, everything I built carried the same line: “Developed by Jay Stants.” That was fine when it was one project and one person. It stopped working once I started thinking about a second product, and a third, and what I wanted them to have in common.

A personal name is a poor container for that. It says who typed the code. It doesn’t say what the work is for. StatikNet is my attempt to answer that second question in a way I can stand behind.

Where it comes from

I’m based in Rochester, NY, and I spent a long stretch of my career in network engineering, infrastructure and automation. That history matters to how I work. I like systems that behave predictably and fail in ways you can diagnose. I distrust anything I can’t test.

It is not the identity of the studio, though. StatikNet is not a networking company, and the name is a nod to a former life more than a description of what we make. We build ordinary products for ordinary problems, and the first one is a gift planner.

Three ideas I try to work from

The studio runs on three phrases. They sound like brand copy, so here is what each one means when I’m deciding something.

Useful by design means a feature has to earn its place by removing a real annoyance. If I can’t name the annoyance, the feature waits. Most of the work is cutting.

Human centered means I start from how people actually behave, which is often messier than a product spec assumes. People forget things, type in a hurry, and change their minds. The software should cope with that instead of scolding them for it.

Engineered with care means the unglamorous parts get attention too: tests, error states, the email that arrives on the right day. Care is mostly a habit of checking your own work before someone else has to.

What we will and won’t be

We will stay small. One person building carefully can say no to a lot, and I intend to keep using that.

We will build products around real needs and talk about them plainly. When something doesn’t work yet, we’ll say so. The Journal is where I’ll write down what I’m learning, including the parts that went badly.

We won’t chase every trend because it’s loud this month. I use AI coding tools heavily, and I’ll write about that honestly, but the studio is not an “AI company” either. The tools help me build. The reason for building comes from somewhere else.

We also won’t pretend to be bigger than we are. There’s no team page full of stock photos, no invented numbers, no vague promises about the future. If you read something here that sounds like a press release, call it out.

What’s here now

GiftLoom is the first product. It’s a gift planner for birthdays and holidays, and it’s available to founding households while I build it with their feedback. You can read more about how it came together in the GiftLoom post.

I don’t know exactly what the second product will be. I’d rather find out by shipping the first one well and paying attention to what people say about it. That’s slower than announcing a roadmap, and I’m fine with that.

If the idea of a small studio making useful things carefully appeals to you, stick around. And if you have a problem that’s been bugging you for years and nobody has fixed it properly, I’d like to hear about it.

Keep reading

AI

Lessons from building with AI agents

AI coding agents are fast, but speed isn't the same as correct. What I've learned about small scopes, independent checks and who owns the decisions.