This content originally appeared on dbushell.com and was authored by dbushell.com
I’ve been on a bit of a journey ever since I shamed myself into rolling my own accounting software, henceforth The App. To buck a trend, I’m coding The App vibe-free without “AI” because I’m an adult capable of writing my own technical debt thank you very much.
This project is a terrible idea that could destroy my business. But like my review of Severance, it’s a risk I’m willing to take!
The plan
The App needs to handle the following entities as minimum:
- Contacts (my clients)
- Projects (their projects)
- Timelogs (day to day hours)
- Invoices (hours logged × rate)
- Transactions (banking + expenses)
Naturally I was immediately distracted by a side-quest of building a GitHub contributions inspired calendar for my timelogs:
This serves no purpose other than to populate an empty “home” page.
Starting this project mid-Feb, I set myself a deadline of the new tax year (6th April). In April I’ll cancel my FreeAgent subscription and export all data. I then have until the tax deadline for self assessment (31st Jan, 2026) to import at least 12 months of data and add a few numbers together.
If this project fails I go to tax prison. No sweat!
Project entities are assigned to Contacts. Timelogs are assigned to Projects and optionally Invoices (if they’re billable hours). Invoices are assigned to Projects. Transactions can be assigned to Invoices if they’re payments. That’s the basic idea.
Every entity has a unique ID (Bun goes up to 7) in the relational database. If only I knew my IT A-level would come in handy one day…
17 year old me didn’t think he’d need database normalisation in future.
Let’s see it then!
Did I mention The App was a self-hosted website? I’ve been building it on and off for the past month. It’s running on localhost for the time being. I’ll discuss the tech stack later. Below is an actual screenshot of my Timelogs page:
The “Week of” grouping is a little janky I need to fix that. Below is another screenshot of a Project page. Please excuse the redacted text! There are UI design tweaks I need to make like limiting the mile-long form elements.
As you can see, I’ve built a lot of functionality and most “MVP” requirements are met. Meaning technical it works but the user experience is lacking.
The largest and perhaps most crucial task of The App is to generate invoices. I have not sent a printed invoice in ten years but it still feels professional to generate an A4-sized letterhead-ed PDF. To do this I spent an entire day writing a responsive print stylesheet. With that I just “Print > PDF” in the browser. This allows me to print US-letter size for clients across the pond.
Ain’t that a work of art!
Now is a good time to discuss the tech stack that got me this far.
Front-end UI
Last year I designed a personal pattern library. It’s nothing fancy. I update it regularly to learn new CSS that might be available outside of Chrome one day. This library allows me to quickly whip up front-end UI for personal projects. It’s not an open source library I want others to use — I refactor on a whim — but it’s open to nosey around.
I’ve found that component ‘scoped’ styles (just classes) + utilities classes for layout (chiefly flexbox) is a powerful combo. I’ve written very little bespoke CSS for The App.
Backend API
The App is powered by a back-end database served by Bun and SQLite. I’m using the ArkType library for validation and type safety on both ends of the API. I’m liking ArkType, it feels snappier than Zod. I’m using Drizzle to avoid rawdoggin’ SQL for the most part. I’ve never found an ORM I like but Drizzle is the least offensive. The back-end API is standard RESTful† stuff. Finally, I’m using Hono for routing.
†I’m not entirely sure REST means what I think it means.
SvelteKit
The front-end client is served by SvelteKit. If you don’t know SvelteKit it’s built with Svelte which is like React, except modern, and designed for the real web. SvelteKit is kinda like Next.js except it does everything right that Next.js does wrong. This gives me a performant and accessible server-rendered website. The DX is fantastic too.
Server routes that fetch data for a CRUD-heavy site become repetitive. Nothing a little abstraction can’t ease. The myriad +page.server.ts and +page.svelte file names are a pain. I know the official advice is “deal with it” but file lists and tabs are not easy to navigate. It’s valid criticism, even if there isn’t a better alternative.
On the whole, SvelteKit is pleasant to use. I’ve used it on a couple of UI/form heavy client projects too. It doesn’t abstract too far away from web standards.
Svelte 5
Reactivity in Svelte 5 is so much easier than previous versions. There’s been negative opinions on this but I personally find Svelte runes more intuitive. The old $: label syntax always felt hacky to me. I wasn’t fond of Svelte stores either, and with Svelte 5 I’ve never needed them. I’m undecided on snippets, they’ll take some getting used to.
These days I’d probably never used Svelte outside of SvelteKit. Plain old JavaScript suffices for most of the websites I build. Be that as web components or otherwise.
What’s next?
That’s all for now! I have another six months to dogfood The App and fix bugs.
If you never hear from this project again, I’ve binned it and gone crawling back to FreeAgent. If you never hear from me again, I’m in prison for tax-related mishaps.
Side rant incoming!
Discord 😡
Discord is where the open web goes to die. Why do so many tech projects insist on hiding knowledge inside a walled garden? Discord is private by design.
To illustrate my annoyance, I was searching the web for an ArkType question and found a partial discussion on what appears to be either:
- a Discord scraping content farm
- an attempt at providing a solution to the Discord problem
Either way, there is clearly knowledge lost to the web inside the ArkType Discord. I don’t mean to pick on ArkType here, it just happens to be my most recent example.
Open source projects are not required to provide “tech support”. Most rely on their users helping one another, sharing knowledge to common problems. Surely it’s best for the project to keep that discussion on the open web?
To be fair to Discord, it’s an OK platform for private communities (besides being a bloated React monstrosity.) The problem is misuse of it. By all means keep your private Discord community, but please direct Q&A to a public forum. 🙏
Whatever happened to forums? Discourse is another JavaScript monstrosity (Ember, I think), but at least Discourse forums are websites.
TL;DR: Discord bad 👎 Websites good 👍
This content originally appeared on dbushell.com and was authored by dbushell.com
dbushell.com | Sciencx (2025-03-28T10:00:00+00:00) Vibe-free SvelteKit for Fun and Profit. Retrieved from https://www.scien.cx/2025/03/28/vibe-free-sveltekit-for-fun-and-profit/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.