← Back to blog
engineering
Changelog: the Invoicesp → Kiralytics rename
The boring details behind the rename: domain switch, invoice number prefix, what stayed identical, and the one thing we broke on purpose.
By Team Kiralytics
If you only have two minutes, here's the gist — the technical companion to our Welcome to Kiralytics post.
The old vs. the new
| Before | After | |
|---|---|---|
| Brand | SP Rekayasa Networks | Kiralytics |
| Domain | invoicesp.sprekayasa.com | kiralytics.com |
| Invoice prefix | SPRN-YYYYMM-NNNN |
KLT-YYYYMM-NNNN |
| DB schema | same | same (column default flipped for new signups) |
| Auth | Neon Auth (Google, GitHub) | + email + password |
| Marketing site | none | landed at /, blog at /blog, docs at /docs |
What stayed exactly the same
- Database URL and schema — no data migration. We copied the prod branch over a maintenance window. Forty-one rows across fifteen tables moved; IDs preserved.
- Session cookies — same Neon-Auth scheme; same secret rotation policy. The only difference: a new
kiralytics.comhost instead ofinvoicesp.sprekayasa.com. - API contracts — your existing scripts/integrations keep working.
What broke on purpose
Only one thing: the next new signup gets a different DB column default for settings.business_name
(now 'Kiralytics' instead of 'SP Rekayasa Networks'). Existing users keep their saved business name.
The reason isn't branding — it's that the only constant in software is change, and the default a new user sees shouldn't be a name from three years ago.
What we did NOT do
- We did not split the marketing site into a separate repo. The
(marketing)route group inside this SvelteKit app is enough for the next year. - We did not migrate off Neon Auth. The "Continue to neon.tech" Google consent label is a managed-auth trade-off we accept and document.
- We did not change invoice numbering for already-issued invoices. Past invoices still say
SPRN-...; new ones sayKLT-.... We could backfill, but it's cosmetic and it'd break audit trails.
That's it. Two minutes.