DEV Community: BezaCore Labs

Why every engagement is fixed-price

Joseph Soper — Fri, 31 Jul 2026 00:26:31 +0000

I quote fixed prices. Every engagement, agreed in writing before any work starts. Here’s the thinking behind it.

Hourly billing rewards the wrong things

When you bill by the hour, the slow, meandering version of the work pays better than the fast, focused one. That’s a strange incentive to put between a studio and the people it’s trying to help. It also means you can’t really budget — the final number is a mystery until the invoice lands.

Fixed scope keeps both sides honest

Before anything starts, we write down exactly what’s included and what isn’t. You know the price. I know the boundaries. Nobody’s watching a meter.

You can budget. The number is the number.
I’m rewarded for being good, not slow. Working efficiently helps both of us.
Scope creep is a conversation, not a surprise. New requests get re-quoted openly, never quietly billed.

The one exception

Ongoing support is the exception, because “keep helping as things come up” genuinely doesn’t have a fixed scope. That’s what the retainer is for — a monthly block of hours at a clear rate.

Start small if you want

If committing to a fixed price still feels like a leap with someone new, the $500 Infrastructure Audit is a low-risk way to see how I work before a bigger build.

Clear scope, clear price, written down. It’s better for everyone — including me.

Shipping is the easy part. Running it is the job.

Joseph Soper — Mon, 27 Jul 2026 23:37:22 +0000

Most software relationships end at the handoff. The repo gets transferred, the invoice gets paid, and everyone moves on — until something breaks in production and it’s suddenly unclear whose problem it is.

I build the other way. Deploying the thing and keeping it running are part of the job, not a separate contract you go shopping for later.

The handoff is where projects quietly fail

A working app on a developer’s laptop is not the same as an app that stays up under real traffic, recovers from a bad deploy, and tells you something’s wrong before your users do. That gap — between “it works” and “it keeps working” — is where a lot of small teams get stranded. They hired someone to build it, and now they need someone else to run it, and the two don’t quite talk to each other.

One studio, the whole lifecycle

At BezaCore Labs the same person who builds it also containerizes it, sets up the pipeline, deploys it to Google Cloud, and wires up monitoring. Not because it’s fancy — because the person who wrote the code is the one best placed to keep it healthy, and because I’ve spent years on the operational side cleaning up systems nobody planned to run.

In practice that means:

Infrastructure as code, so the setup is reproducible instead of a pile of manual clicks nobody remembers.
Monitoring and alerts, so problems surface on my screen, not in your support inbox.
Backups you can actually restore, and a written recovery path — tested, not assumed.

Why it matters to you

You get one accountable studio from the first commit to live traffic. When something needs attention, there’s no finger-pointing between “the dev” and “the ops person” — it’s the same studio, and it’s already watching.

Shipping is the easy part. Running it is the job.

I had a blog with no pipeline feeding it

Joseph Soper — Sun, 26 Jul 2026 02:12:08 +0000

Building in public is part of how this studio is supposed to work. It's in the go-to-market plan in plain language: don't buy attention, earn it by showing the work.

Then I shipped this blog, wrote two posts about how I run engagements, and noticed something uncomfortable. There was a publishing surface and there was plenty of real work happening behind it — two products in flight, a homelab platform, a client site — and absolutely nothing connecting the two. No pipeline. No cadence. Just a good intention and an empty queue.

Intentions don't survive contact with a build day

The obvious fix is "write a post about what you did today." I've tried that version. It fails for a boring reason: at the end of a long build session, writing a polished post is a tax, and taxes get dodged. You skip one day, then a week, and then you're staring at a blank editor trying to reconstruct what you did on a Tuesday eleven days ago.

That reconstruction problem is the one that actually worried me. My words at the time were:

I don't want to be 70% done and trying to remember what I did on day X.

The interesting details — the bug that took three hours, the tradeoff you agonized over, the thing that surprised you — have a short shelf life. They're vivid the day they happen and gone by the weekend.

So the tax has to come off the writing, not off the remembering.

Capture daily, publish weekly

The system splits into two tiers that cost very different amounts.

Tier one is capture, and it's about a minute. At the end of any session that produced something real, I drop one to three raw bullets into a build log: what shipped, why it's interesting, and a link. Bullets, not prose. No editing, no audience in mind. If a session wasn't post-worthy, I write nothing — not everything is content, and pretending otherwise is how you end up publishing filler.

Tier two is the distill, once a week. I read the week's seeds, pick one angle, and write a single post from it. One post, one idea. The raw material is already sitting there with the details intact, so the writing session is actually writing instead of archaeology.

The split matters because it puts the expensive step on a schedule I can defend and the cheap step where the memory actually is.

The part I got wrong on day one

I built the capture layer as a single central file. Every project's seeds in one place. It lasted about a day before it felt wrong — I was recording each project's story outside the project, in a file that belonged to none of them.

The instinct was to flip: give every project its own log. But then the weekly distill has to go hunting across a dozen files to find out which ones changed this week.

Central or per-project looked like a real tradeoff, and it wasn't one. My notes live in Obsidian, which has a feature — Bases — that generates a live index from every file matching a query. So each project got its own build log at its own root, and one auto-generating view rolls all of them up, sorted by most recently touched. Locality and a single pane of glass, no maintenance, nothing to keep in sync.

The lesson generalizes past note-taking: when a design feels like it's forcing a choice, check whether something already in your stack dissolves the choice before you spend an afternoon defending one side of it.

Make the habit structural

The last piece is the one that decides whether any of this survives past week three. I already run a scripted wrap-up ritual at the end of every session — update the roadmap, sync the work tracker, write the journal. The build-log capture is now a step inside it.

That's the whole trick. It isn't willpower or a calendar reminder. It's a step in a checklist I was already running, positioned at the exact moment the material is freshest. Habits that depend on remembering to have them are not habits.

Write once, publish everywhere

Because the expensive part is the thinking, not the typing, one post should reach more than one audience. This blog is canonical — it's the surface I own, and it's where the SEO accrues. From there the same post goes out as a full copy to developer communities with a canonical tag pointing home, and as native text on LinkedIn, where external links get suppressed so the link lives in the first comment instead. A short thread on X and Bluesky gets added once the weekly rhythm is real, rather than stalling the habit on format-wrangling before there's anything to wrangle.

Same idea, four surfaces, one writing session.

This post is the system's first output

There's a certain amount of nerve required to make post one an explanation of how you're going to write posts. But it's the honest starting point, and it's the piece that stops being true the longer I wait to publish it.

Build in public fails as an intention. It works as a system.