I tend to favor boring infrastructure. Boring usually means predictable, debuggable, and hard to accidentally break. Most of Anchorline follows that rule, but one place where I intentionally added complexity was at the edge, using Cloudflare Workers.

First it’s important to know that Anchorline has a lesser-known capability where every user can have their own subdomain and publish public logs. These public logs are meant to be shareable, fast, and cheap to serve. At the same time, the private Anchorline API is locked down behind Cloudflare Access, and the public pages are served by a simple Node app running on Cloudflare Pages.

Because all of this lives in the same Cloudflare Zone, I was able to introduce a Worker that sits in front of every request and acts as the traffic coordinator.

So now when a request comes in for something like xyz.anchorline.io, it hits the Worker first. The Worker determines whether that subdomain is public, where it should be routed, and whether it should be proxied, rejected, or passed through untouched. Not all subdomains are public, and handling that distinction at the edge keeps the application code simpler and safer.

Now a bit about caching since this has been a bonus byproduct of how this worker is setup. All user public subdomains are cached at the edge indefinitely. When data backing a public log changes, the cache is explicitly purged and immediately repopulated on the next request. The result is that public pages serve almost entirely from cache, and the backend API only sees traffic when data actually changes. This keeps bandwidth usage low and removes load from the API without introducing stale data issues.

I am intentionally skipping the detailed caching mechanics here, because they deserve their own post. The important point is that the Worker makes the rules explicit. Nothing is cached by default, and nothing is uncached by accident.

One critical detail that made this setup reliable was careful use of Worker Routes. The Worker only runs on the routes it is responsible for, and is explicitly disabled on paths and subdomains where it should not interfere. Without this scoping, it is easy to create subtle bugs where edge logic leaks into private or internal traffic not to mention you quickly end up paying for requests that are entirely unnecessary. By removing them from the route you cut them off before they hit the worker and cost you a request.

This setup has taken many iterations to get right. It is slightly less boring than pure app-level routing or static rules, but in practice it has been stable and easy to reason about. More importantly, it keeps edge concerns at the edge, instead of spreading routing and caching logic across multiple codebases and dashboards.

So far this additional complexity has far outweighed the downsides.

So who is this post for? This post is for anyone in the pre-launch stage of developing their SaaS or even still in the idea stage that wants to know what it truly takes to bring their idea from just that an idea to launched 🚀. I’m going to cover the topics that don’t often get discussed but are some of the most important parts of getting to launch day successfully.

Operational Readiness

In my opinion, this is probably one of the most overlooked steps that newer founders make on the journey to launch. So what is operational readiness?

It’s simple, you remove the unknowns.

Unknowns about deployments, unknowns about security, unknowns about data integrity, etc..

• Do you have the capability to deploy a hotfix at 3am?

• Do you have the monitoring to surface errors?

• Do you have the understanding of how to rollback a failed deployment?

• Do you have the playback for restoring your database due to data loss?

• Can you scale your services because of peak traffic?

• Do you have alerts for the performance of your hardware?

These are the types of questions that you want to answers to prior to your launch and they don’t take nearly as long to answer as you would think. Especially when you are able to answer them while not already in a crisis.

“Operational Readiness” is the prerequisite to “Operational Calm” and that calmness creates trust. When issues crop up they are just handled. Why? Because you took the time to playbook them before it was a crisis.

Product Boundaries

One of my all time favorite tv shows is Halt and Catch Fire and at one point in Season 3 Joe MacMillan erases a whiteboard filled with ideas. Ryan Ray protests but Joe says (and I’m paraphrasing here) “Anything important enough to be on that board we’ll remember tomorrow”. This scene has lived rent free in my head ever since I’ve seen it and speaks to a lot of what founders deal with in terms of product boundaries. Scope creep is real and insidious. By the time you realize it the sunk cost fallacy rears its head and what was just a nice feature before launch has pushed things back by weeks if not longer.

For the launch of Anchorline I was obsessive about ensuring this did not happen this time. And for the most part I was successful. I shipped a bare bones export that allows users to get their data out if they like but cut import entirely for launch. Filtering, search, and sorting for a lot of tables got punted. I wanted a more feature rich collection of presets but ultimately settled on what I could get done in a few hours. Being surgical about what I punted let me focus on the areas where I wasn’t willing to compromise.

For example, onboarding was extremely important to me and I take a lot of pride in the work I did there. It took me nearly two weeks to get the onboarding flows exactly how I wanted them but I really wanted users to have a pleasant onboarding journey and not just get dropped into an empty admin left to figure things out on their own.

Trust Your Primitives

Similar in vein to “Operational Readiness” but where that is about your ability to act, trusting your primitives is about which failures are unacceptable. So what am I referring to when I say primitives? They are what I would call a class of systems that exist in every SaaS that you do not have the luxury of getting “mostly right”. They are not features, they are primitives.

• Auth

• Billing

• Data Models

• Backups

• Privacy

• etc..

Auth should not “mostly work.” Billing should not “usually be correct.” Data should not “probably be safe.” These are not areas where recovery is good enough. They are areas where correctness is the expected baseline.

Shipping features on top of any untrusted primitives does not increase speed to launch it only increases the blast radius.

The most useful rule of thumb to follow in this area is if a failure in this system could permanently lose you user trust then you need to really stress test it prior to launch.

Narrative Clarity

Before launch, you need a description of your product that you can repeat without adjusting it for the audience. I want to be very clear here, this is not marketing copy. It is not a pitch. It is the answer to a simple internal question: what is this thing, and just as importantly, what is it not?

If your explanation changes depending on whether you’re talking to a developer, a potential user, or a friend, that is a sign the product boundaries are still fuzzy. So when a potential user asks what the product is for, you should not be inventing language on the fly. Once people form their own mental model of your product, correcting it is far harder than preventing it.

Personally, I underestimated how long this takes especially because in my case Anchorline is genuinely complex. It’s a system with a mental model, and most people will try to map it onto something they already know, spreadsheets, Notion, etc.. so for me it took nearly 2 mos. to arrive at something I was happy with.

Once that description finally settled, everything else got easier. It clarified how I talked about the product, influenced product decisions, and shaped the direction of the marketing.

What You Don’t Need

Now here is what you don’t need and I expect that some of these will be slightly controversial. Most pre-launch advice that you’ll read is going to be frame around accumulation. More users, more validation, more certainty, more momentum. But none of those are prerequisites for the single most important thing .. shipping.

• You do not need an audience. Many of the most successful products launch quietly and only find their users later.

• You do not need the perfect roadmap. Roadmaps created before real usage are mostly guesses, and they tend to anchor you to decisions made without evidence.

• You do not need external validation to get started. It is very easy to get people to say they would pay for something. That does not tell you whether they will break out the wallet once it’s actually time.

• You do not need external validation to get started.

• You do not need certainty. And lets be honest you’re not going to get it.

Closing

Launch day is where the real accountability for your SaaS begins. Mistakes move from private and theoretical, to public, real and at time embarrassing. If your launch is boring, uneventful, and anti-climactic then I would wager that your founder journey hit a lot of the points above.

Coming out of the public launch I thought it would be interesting to do a quick overview of the infrastructure choices behind Anchorline and why they were made.

Backend Services

First and foremost the Api for Anchorline and the databases are all hosted on Fly.io servers. When deciding on the backend hosting provider managed Postgres mattered, but the bigger win is how little attention Fly needs once it’s set up.

The API is written in Bun using Hono and personally I’ve found that this setup is fast and simple. Startup times are low, request handling is efficient, and the framework does not add much overhead. There is very little abstraction between the app and the platform, which keeps things easy to reason about.

Frontend Services

The frontend client is built with Next.js and hosted on Vercel.

This is my first production app deployed on Vercel and it has been smooth so far. Setting up dev, QA, and prod environments was painless. Preview deployments work out of the box, and promoting changes through environments is straightforward.

Since Vercel builds and maintains Next.js, the integration feels natural and avoids a lot of custom deployment work.

Cloudflare

The main anchorline.io site is hosted on Cloudflare and I rely on it heavily for security. Bot Fight Mode and Zero Trust handle most of the protection, and Cloudflare Access sits between the app and the API to add an extra layer of control. Edge caching is a nice bonus.

Managed Services

In addition to hosting, Anchorline relies on a number of managed services:

• Stripe for billing

• Umami for analytics

• Sentry for error tracking

• BetterStack for status monitoring, with a possible move to OpenStatus later

• Google Workspace and Resend for email delivery

• GitHub for private repositories

None of these choices are exotic, and that’s intentional.

It takes a fair amount of work to put together an app that is stable, performant, and scalable, but the payoff is that things mostly just work. When it comes to infrastructure, I strongly prefer boring, and this setup has been boring in exactly the right ways so far.

Anchorline, which I have dubbed a spreadsheet alternative for everyday life, is finally out of private alpha.

The last few months have been a blur. A lot of building, rewriting, fixing things I thought were done, and discovering new problems five minutes after declaring something “solid.” At some point it crossed the line from “I’m still experimenting” to “this is becoming real”.

There’s a lot I want to write about how it works, why it’s shaped the way it is, and what surprised me along the way. But for now it’s Christmas and I’m going to enjoy the next few days after an intense period that brought me to a public launch.

It’s early, it’s real, and there’s a lot more coming that I couldn’t be more excited about. For now if you’d like to check it out please signup for the free trial and let me know what you think. I hope that everyone has a wonderful holiday and at the risk of sounding like a walking cliché; stay tuned, more details soon.

One of the things that I discovered just recently is that you can store your API Key in 1Password and have Claude read it at runtime instead of storing it with Claude directly.

Note: This is only useful if you are using the Claude API. If you’re using one of the general plans you won’t need this flow.

Setup 1Password

To get started the first thing you need to do is download the 1Password CLI tool.

Next you’ll need to create a new shell file in your .claude directory that will read your API Key from 1Password. For my purposes I simply called it claude_key.sh which has a single line:

op read “op://MyVault/Claude Code API key/credential

Make sure to set your new file to be executable so it can actually run the 1Password command:

chmod +x ~/.claude/claude_key.sh

.claude Settings

Lastly, you’ll need to open your Claude settings.json file and set the parameter apiKeyHelper to point to this new file on your system.

{ apiKeyHelper: ‘./claude_key.sh’ }

Done!

That’s it! Now launch Claude Code and it’ll attempt to read your API Key from 1Password so you’ll get asked by 1Password to open your vault. And it will read it this way everytime you start a new session.

— Lauren

I used to equate these long hours with progress, but now I mostly see them as debt just waiting to be paid down. The idea that a good day means pushing through to exhaustion doesn’t hold anymore and I find that it’s better to stop while you still know what’s next.

I’ve started working in shorter stints. The context stays tighter, and I’m less likely to find myself walking into dead ends or end up on wild goose chases. Through maturity I’ve learned to pause when I lose focus and I now find the gaps in between have become useful. A walk, a few notes, small resets do more for clarity than I find another hour at the keyboard ever did.

Planning, reorganizing folders, sketching next steps before touching code. None of it looks productive in the moment, but it makes the rest of the work go smoother. Most of the chaos comes from skipping this part and I’m finding my new found patience pays dividends on the backend.

Messages and meetings still happen, but they don’t set the pace anymore. I answer things in batches and let the rest wait. Most of what feels urgent rarely is. It reminds me of that moment in Halt and Catch Fire when Joe MacMillan wipes the whiteboard clean and Ryan gets upset. Joe tells him it doesn’t matter — whatever was important, they’ll remember.

The shape of work now is slower but steadier. Mornings carry the heavy lifting, afternoons taper off, nights are mostly for everything else (posts like these!) enough structure to keep moving forward without burning through it all at once.

— Lauren

Budget apps like YNAB or Mint always looked promising, but I could never keep them alive for long. They want precision and discipline, which are great in theory but too rigid in practice. I found myself spending more time correcting the software than understanding the numbers. Over time it became a chore and the value I got from them was less than the value I extracted so they would naturally fall away. I think over the years I’ve given YNAB alone 4 different tries with the most recent one being earlier this year and again it just never sticks.

Note apps like Obsidian, Notion, and Bear were another recurring experiment. I hear so many wonderful things about these apps so I always feel as if I’m missing out. Every few months I’d rebuild a new system from scratch, folders and tags and backlinks, all with good intent. A week later I’d forget about it and go back to plain text. The notes outlast the structure every time. My go to is CMD+N on VS Code and notetake there and as clunky as it is, it just seems to work for me.

I tend to default back to Google Meet despite trying to make Zoom stick. It isn’t better, but it’s simpler and it gets out of the way. The goal is to talk, not to manage another interface and the fewer desktop apps I have to open on a daily basis the better my day seems to be.

Hey! (the email service not the exclamation) was another that I wanted to work. I liked the design and the opinions behind it, but I kept finding myself back in a plain desktop client. It does seem that I tend to default back to boring really is better.

Discord falls into that same category. I like the idea of it, but I never found a rhythm there. It always feels a little too much like shouting in a crowded room, and I’ve never been good at that kind of noise. It’s another where I feel I miss out on some of the hype but that’s never been enough to keep something as a mainstay for my use.

These are all tools I wanted to love, but that’s not enough to make them last. The ones that stay are the ones that quietly fit into the system of you. The rest fade, leaving behind exports, empty workspaces, and the quiet realization that usefulness isn’t universal.

— Lauren

The command line and VS Code are where quite a few of my daily hours go. The CLI is quiet and predictable, a place that doesn’t need to explain itself. Over the years I’ve experimented with moving all my coding to being CLI based but I always drift back to an external editor. VS Code adds just enough comfort to make the work enjoyable: syntax highlighting, split panes, a little visual context when you’ve been buried in text too long. Between the two, I can move fast, break things, and fix them again without frustration.

Then there are the tools that simply exist as an integral part of life for better or worser: spreadsheets, email, and Slack. Spreadsheets still handle the messy middle of projects where structure hasn’t quite solidified. Email remains clunky but indispensable; it’s the only medium that still behaves like correspondence. And Slack… well, I use it too much. I haven’t figured out how to escape it yet, but at least it’s searchable.

After all the churn, that’s what remains as my daily drivers: tools that don’t try to impress you. They just work, quietly, the same way every day. Stability might not be exciting, but it’s what keeps me moving forward.

Maybe one day Anchorline will earn a spot on this list. Not because I build it, but because it has become that ingrained in the system of me.

— Lauren

When automation gets in the way

Modern finance apps are built for scale, not understanding. They assume you want to optimize for time, for returns, for “insight.” Open any popular budgeting app and you’ll find the same promise: connect your bank account, and we’ll do the rest.

They import your transactions automatically, label them for you with machine learning algorithms, and feed you dashboards meant to summarize your life into green arrows and pie charts. But that’s not understanding.

The fundamental problem with automated finance tools is that they conflate convenience with clarity. Yes, it’s convenient to have transactions imported automatically. But clarity requires something different. It requires you to actually look at each transaction, to make a conscious decision about what it means, to integrate it into your understanding of your financial situation.

Automation promises to save you time, but what it actually does is save you from thinking. And in personal finance, thinking is not a bug to be eliminated. It’s the entire point.

The burden of flexibility

On the other end of the spectrum sits the spreadsheet: beautiful in theory, fragile in practice.

I know this intimately as I’ve been maintaining a personal finance spreadsheet for nearly 20 years. It started simple and elegant, a few columns to track income and expenses along with a summary tab with some basic calculations. But after two decades, it has grown into something else entirely: a sprawling, interconnected web of tabs, formulas, and historical data that I’m now mostly afraid to touch.

The spreadsheet contains the best financial history of my adult life that I have available and while that should feel empowering it instead feels oddly paralyzing. There are formulas in there I wrote 15 years ago that I no longer fully understand or appreciate. There are workarounds built on top of workarounds, special cases accumulated over time to handle situations that seemed temporary but became permanent.

Want to change how I categorize something? I have to trace through multiple tabs to make sure I’m not breaking a calculation somewhere downstream. Need to add a new account? I have to figure out where it fits in a structure that made perfect sense in 2008 but feels arbitrary now.

This is the paradox of spreadsheet freedom. They give you infinite flexibility and zero protection. They can’t tell you when:

• A formula drifts or you’ve accidentally introduced an inconsistency

• A balance no longer ties out to its component parts

• The history of a number disappears into a deleted row

• You’ve built a circular reference that makes your entire model unreliable

It’s control without continuity, freedom without safeguards. My 20-year-old spreadsheet is simultaneously my most valuable financial tool and an increasingly unwieldy relic. I depend on it, but I don’t entirely trust it anymore. And the thought of migrating to something else, of somehow extracting and preserving all that history, feels overwhelming.

The spreadsheet hasn’t failed me, exactly. But it has taught me something important: flexibility without structure eventually becomes its own kind of prison.

The missing middle

This is where Anchorline comes in, sitting in that uncomfortable gap between structure and freedom, between the rigidity of accounting software and the chaos of spreadsheets. It’s not trying to be either one.

It’s a ledger built around one deceptively simple rule: append, never edit.

Every entry is written once and preserved forever. If something changes, you don’t go back and modify the past. You record the change as a new event, a new line in the ledger. That’s it.

From that single rule comes something remarkable: trust. Because entries are never modified, balances can be replayed from scratch at any point in time. You can ask “what did I have in savings on March 15th?” and get a reliable answer, built up from the immutable history of every deposit and withdrawal.

Collections form clear chains of ownership and meaning. You can see exactly where something came from and where it went. You can track savings, expenses, or projects the same way, consistently and audibly, without needing to wrap your head around double-entry accounting or navigating enterprise software designed for companies with compliance requirements.

The append-only model does something else too: it changes your relationship with mistakes.

• In a spreadsheet, a mistake is dangerous. You might have overwritten important data, broken a formula, corrupted your entire system.

• In an automated app, you might not even notice a mistake until it’s been compounding for months.

• In an append-only ledger, a mistake is just another entry. You see it, you record a correction, and the full history (including the mistake and its fix) remains visible.

There’s no fear, no hidden corruption, just an honest record of what actually happened.

Deliberate systems

Most software tries to save you time, to make things faster and more efficient. Anchorline has a different goal: it tries to give your time structure.

Typing a line into a ledger isn’t busywork that should be automated away. It’s an act of attention, a moment when you pause and acknowledge what’s actually happening with your money. It’s how you stay in touch with where things stand, not through a dashboard or a summary, but through the accumulated practice of recording what matters.

This might sound inefficient to people who’ve been trained to optimize everything. But efficiency isn’t always the right goal. Sometimes what you need is not to move faster, but to move with more awareness.

When you manually enter a transaction, you think about it. You notice patterns you wouldn’t see in an automated feed. You catch errors immediately rather than discovering them months later. You maintain a relationship with your financial reality rather than outsourcing it to an algorithm.

It’s not about optimization. It’s about orientation. Knowing where you stand, how you got there, and what it means. When you can’t erase, when every entry becomes part of a permanent record, you have to think clearly before you write. That constraint isn’t a limitation. It’s a feature that makes you more thoughtful, more deliberate, more engaged with the system you’re building.

Anchorline wasn’t built for accountants who need to prepare financial statements or comply with regulations. It was built for people who like to keep things in order and want that order to last. People who understand that the goal isn’t just to track numbers, but to build a system they can trust six months or six years from now.

People who recognize that the act of maintaining a ledger is not separate from understanding their finances. It is understanding their finances, one deliberate entry at a time.

I plan to get into more specifics for how Anchorline has grown beyond its original finance roots in future posts but I did want to offer this unique perspective on where it sits on the finance spectrum given that was the start for it.

— Lauren

Most of what’s happening right now isn’t glamorous. It’s the quiet, repetitive work of seeing where ideas hold up and where they don’t. Every time someone starts a new ledger and shares feedback on their experience I learn something about how flexible the structure really is. Some are tracking savings and budgets. Others are logging books, collections, or ongoing projects. One person built a ledger for home maintenance and wanted to tag entries with photos of their repairs. I didn’t design it for that, but it’s this type of feedback that is inspiring.

My nights and weekends are spent tuning small things. Rollups, exports, and the way parent and child ledgers talk to each other. The goals are simple in theory but the work to tame complexity into something seemingly simple and frictionless is where the challenge lies. I’d rather fix one real problem at a time than chase growth. The alpha isn’t about scaling; it’s about trust. Getting the foundations solid before anything else.

So that’s where I’m is right now, still in those early, quiet days. If you are interested in seeing what it’s about please signup for the Anchorline waitlist. The feedback is beyond invaluable in shaping the product during its infancy.

Anchorline started from a simple frustration. I wanted to track a few savings goals like a vacation fund, a car fund, and an emergency reserve, and still see how they all rolled up into one total. Every product I tried either broke the hierarchy or lost the context. I didn’t want dashboards. I wanted ledgers that never forget, where every change adds to the story instead of replacing it.

So I built one.

At first it was just a balance ledger that could have child ledgers nested underneath. Then came collections, ways to track things that aren’t numbers like books, gear, recipes, and notes. It turned out the same model worked everywhere. Anything worth tracking could live inside a hierarchy, append-only, with its own context and history intact.

That’s how the idea grew from a personal tool into Anchorline, a universal ledger for the business of life. A system that treats money, inventory, or even a reading list with the same integrity as a financial statement.

No overwriting. No hidden state. Everything explainable and exportable.

This blog is a way to peel back the curtain and show how Anchorline is built. It’s where I’ll share product decisions, technical details, and design philosophy in real time. Think of it as the development ledger, an ongoing record of what I’m learning, what’s changing, and how the system is evolving.

If you’ve ever wanted a way to track things that respects time and structure, welcome aboard.

- Lauren, for the Anchorline team (it’s actually just me)

Subscribe now