[brailsafe]

> because why not?

I'm not certain, but it seems like you're not being entirely serious here, however..

If you aren't joking, or for other people in this position, I'd first wonder if the landing page required a search function that would hypothetically be subject to the vulnerability, then I'd wonder about what the normal nature of your business is and how much latitude you personally have in the allocation of billable hours to arbitrary technology choices and whether those do actually align with the deliverable, then if I was the boss I might wonder why you created a bunch of (potentially) out-of-scope random liability using unusual lesser-known tools based on a personal vendetta against WordPress.

I've been in this position, conceptually if not literally, and I've probably been (in a way, rightfully) fired for it, but my country's labor protections are likely not quite as good as Denmark's.

If there's a question about why money was spent on implementing a bunch of stuff nobody knows for a reason nobody cares about, especially for a very short-lived thing like a landing page, then it's a sticky situation if the answer is basically novelty. Something like this, if it does serve a purpose, should be planned for and a case made for it, but that also doesn't really seem like agency work.

If I was asked for WordPress, which I have, and I delivered Rust, I don't think I'd keep that job, but mileage may vary.

Most work is about solving problems as they are, not what we wish them to be, and if a 5 min job becomes a month long job that the customer didn't ask for, it's an extreme case of yak-shaving.

[sshine]

I get what’s you’re saying, and if I couldn’t justify making the best alternative I can imagine in my free time, because I’ve wanted it for a long time, I’d install “a CMS” (not WordPress).

> If there's a question about why money was spent on implementing a bunch of stuff nobody knows for a reason nobody cares about, especially for a very short-lived thing like a landing page, then it's a sticky situation if the answer is basically novelty.

The economy behind a decision like is this: alternative SaaS website builders are $20-60/mo./seat. We’ve historically paid $720/mo. for the ability to edit a single website that doesn’t look great but is dead simple to modify.

So if I can make something that scales up to any amount of sites and any amount of editors with ~10 hours on landing the design (which isn’t included in “a WordPress” either way), at ~$700, then I can justify making ten sites per year at the cost of our first.

Or more realistically: The total operating cost of the current website gives me 125 hours in a year to make something better.

Then the question is not “Can I make something better?” (Yes.) Or “Is it affordable to make something from scratch?” (It is.) But rather: Could I make more money doing something else? (I could halve the Azure budget in less than a month by optimizing and cleaning up.)

[brailsafe]

Makes sense to me, your other comment that elaborated on the scenario adds some useful context. I assumed there was quite a lot missing and tried to frame the comment for future versions of myself that might think it's a good idea to just run with a wildly out-of-scope idea with too much hubris.

[sshine]

> might think it's a good idea to just run with a wildly out-of-scope idea with too much hubris

I'll say that using git as a database instead of simply SQL leads to a lot of corner cases.

For example, you are inside a transaction from the moment you make a single change to anything.

But the filesystem is conventionally thought of as something that can be shared between sessions.

So I need a git worktree per user.

In both my use-cases there's very few users, but if there were two, and they decide to change things independent of one another, then

  - their worktrees will become stale, and I need to add somewhat automated checking how far behind they are
  - their stale worktree will have conflicts, and dealing with merge conflicts in a pedagogical way is a big task
  - working on multiple things at once is possible, but introducing "committed" on top of "draft" + "publish" adds mental gymnastics
  - using the filesystem as a database makes deployment to Kubernetes less trivial because you need persistent storage

One thing you get "for free", though, is authentic preview: Since the final site is a static site, I can just run the generator when the user wants to see a preview.

The nice thing about this is that if you remove the admin dashboard, it's just another static site.

It can be maintained perfectly fine with regular git and e.g. VSCode.

Add Nix + Claude and you have an entirely different mode of operation.

Which is what I like about plaintext (Markdown). It's not tied to any one program.