Hello - and why this journal exists
This is the first entry in what we’re calling the Siktec Lab - a public engineering journal kept by the team at Siktec.
It is not a content marketing site. It is not a launch blog for a product. It is not a place we’ll post recycled framework explainers or “10 things every dev should know” listicles. The internet has plenty of those, and they don’t need our help.
What this is, instead, is the working record of a consultancy that goes deep on one hard problem at a time. We write up the problems that taught us something. We write up the systems we shipped that we’re proud of. We write up the ones we’d build differently next time. The bar for a post existing is simple: would we want to read this if another consultancy had written it?
Who we are, briefly
Siktec is a small engineering studio. We work across what most teams would call wildly unrelated domains - embedded firmware on ESP32-class hardware, high-traffic SaaS platforms, real-time data pipelines, AI infrastructure, ops dashboards, the occasional rescue mission on a codebase that needs grown-up hands. The common thread isn’t a stack or a vertical. It’s depth.
We believe a small team that goes deep on one thing at a time will out-ship a large team that goes shallow on many. Most of what gets published here is field evidence for that bet.
What you’ll find here
A few honest categories:
- Field notes. A specific problem we hit on a real project, the call we made, what it cost, and what we’d do differently. The kind of post we wish other consultancies wrote - concrete, dated, traceable to a real client (within NDA).
- Architecture write-ups. End-to-end traces of how a system is put together - frontend, backend, database, and (when relevant) firmware. The interesting parts are the seams.
- Deep-dives. When a piece of technology is worth taking seriously - Svelte 5’s runes, async Rust under load, SIMD for vector search, append-only storage models - we write it up properly. Long-form. Code. Math when it earns its keep. Diagrams when prose runs out.
- Opinions, sparingly. When a tradeoff is interesting enough to be worth a real take, we take it. Otherwise we don’t.
What you won’t find here
- A posting schedule. We write when there’s something to write about, not when a calendar says we’re due. The result is that some months you’ll get four posts; some quarters you’ll get one.
- AI-generated filler dressed up as analysis. Every post here is written by an engineer who built the thing.
- Affiliate links, sponsored content, or “subscribe to my newsletter” overlays. This journal exists to be read.
Who we’re writing for
Mostly: senior and staff engineers who are looking at a problem we’ve already looked at, and want to know what we’d do. Sometimes: founders and product leads who are trying to decide if a particular technical bet is worth making. Occasionally: ourselves, six months in the future, when we’ve forgotten exactly why we made a call.
If you’re one of those people and a topic here matches something you’re working on, get in touch. We’re always interested in a good problem, and we’re often available to talk through one even if we don’t end up working together.
Where to start
If this is your first time on the Lab, the posts that introduce us best are probably the deep-dives on KAI’s vector search architecture, the training-free quantization behind it, and our working argument for Svelte 5. They’re long. They’re technical. They’re representative of how we think.
Welcome.