Skip to content

Building the systems other software runs on

Frameworks got faster and deploys got easier, but the hard parts stayed hard — state at scale, latency you can feel, tooling that fights you. We think that layer deserves the same attention everything above it has had.

Our story

Spark Golden Tech started with a problem in our own build. Every styling approach we tried shipped a runtime to the browser, and every one of them left accessibility as something you checked afterwards, by hand, if you remembered.

So we wrote our own. traceless-style compiles styles at build time into plain atomic CSS, and breaks the build when contrast fails WCAG. No styling engine reaches the page. We released it under MIT, and this site is built with it.

That is still how we work. We build the tooling we need, run it in production ourselves, and open the parts other teams can use. The systems we take on now — distributed backends, real-time platforms, developer tools — get chosen the same way.

What we believe

Principles that decide how we build, review, and ship.

01 / 04
principles/ship-it

Ship it or delete it

A branch that has not merged in a month is not work in progress, it is a decision nobody made. We keep scope small enough to finish, and we would rather ship a v0 that works than hold a v1 that might.

02 / 04
principles/the-build-reviews

The build is the reviewer

If a rule matters, it runs in CI. Contrast, types, bundle size — checked on every commit rather than remembered during review. A standard that depends on someone noticing is not a standard.

03 / 04
principles/read-the-source

Read the source before you trust it

We publish our tooling because you should be able to check it rather than take our word for it. The same test applies to what we depend on: if we cannot read it, we think hard before shipping it.

04 / 04
principles/no-runtime

No runtime we do not need

Every kilobyte we send is one somebody pays for on a slow connection. We move work to build time whenever it can go there, and we measure instead of assuming.

The founders

Three engineers who started the company around the tools they wanted to use.

  • EL Moustapha Mohamed Sidi

    CEO and founder

  • Mohamed Abdellahi Sidi Heibe

    Co-founder

  • Bechir Cheikh

    Co-founder

Where we spend our time.

Distributed backends
Systems that stay correct when they are split across machines, and stay fast when traffic multiplies.
Developer tooling
Compilers, linters and build-time checks — the tools that make the right thing the easy thing.
Real-time platforms
Event-driven and socket-based infrastructure for software where latency is part of the product.
Security engineering
Zero-trust boundaries and hardened encryption, designed into the architecture rather than wrapped around it.

Frequently asked questions

  • Distributed backends, developer tooling, real-time platforms, and the security engineering around them. We take on systems where correctness and latency are the hard part, and we ship our own tools — traceless-style is the one that is public.

    Read the full answer

  • Our office is in Nouakchott, Tevragh Zeina. We work with engineering teams remotely, and treat written decisions and readable repositories as the default, so where anyone sits rarely changes how a project runs.

    Read the full answer

  • Requirements are turned into checks that run in CI rather than documents reviewed at the end. Where a rule can be expressed as a test — data residency, retention windows, audit trails — breaking it breaks the build.

    Read the full answer

  • The ones where the difficulty is technical rather than cosmetic: high-concurrency backends, event-driven infrastructure, document pipelines that have to verify, and platforms that need to stay fast as they grow.

    Read the full answer

  • TLS 1.3 in transit and AES-256 at rest, with HSM-backed key storage and scheduled rotation. Access is scoped per service and reads of sensitive data are logged. Those boundaries are designed in from the first commit rather than added later.

    Read the full answer

  • AWS, Google Cloud, Azure and Cloudflare, plus bare metal where the workload justifies it. Infrastructure is defined as code, so an environment can be rebuilt from the repository instead of from memory.

    Read the full answer

  • Yes — inference pipelines, evaluation harnesses, and the plumbing that keeps a model predictable in production. Models are measured against held-out sets before release, with regression checks on every update.

    Read the full answer

  • Yes. Documents are produced with embedded fonts and a cryptographic signature, and each carries a verification link that re-checks that signature against the stored record.

    Read the full answer

  • Collection is minimised by default and retention windows are set per data class, in code rather than in a policy document. We work to GDPR and CCPA, and policies are versioned alongside the software they describe.

    Read the full answer

  • Yes. We work inside an engineering team rather than alongside it, and we contribute back to the open source we depend on. Architecture decisions get made together and written down.

    Read the full answer

  • An agreed response window, a named engineer who already knows the system, and access to the same monitoring we use. Post-launch work is scheduled, not squeezed between other projects.

    Read the full answer

  • Horizontally, by design, from the first version — and load-tested long before they meet real traffic. Growth should mean adding capacity, not starting a rewrite.

    Read the full answer

  • Interface work is treated as engineering: a type scale, a token system, and contrast checked by the build. Accessibility is not a review stage that can be skipped, it is a test that fails.

    Read the full answer

  • Yes — privacy policies, terms, contracts and notices, generated as signed, verifiable documents and versioned with the systems they cover.

    Read the full answer

  • Every project ships with a pipeline: typed builds, automated tests, contrast and bundle-size checks, and deployments that do not need a maintenance window.

    Read the full answer

  • Where it is the right tool — verifiable records, signatures, audit trails. We will say so when a database and a signature would do the same job at a fraction of the operational cost.

    Read the full answer

  • Yes. Handover includes the reasoning, not just the repository: architecture walkthroughs, written decision records, and time with the engineers who built it.

    Read the full answer

  • That is the normal case. We start from the constraints that actually bind — throughput, latency, regulation, the systems already in place — and build to those rather than adapting a template.

    Read the full answer

  • Designing for concurrency before it arrives: stateless services, deliberate cache boundaries, and load tests run against realistic traffic rather than a happy path. Most rewrites we are called in for skipped that step.

    Read the full answer

  • One codebase where cross-platform genuinely fits, native where it does not. The test is whether the result feels native to the person holding the phone, not whether it saved time to build.

    Read the full answer

  • Boring dependencies, typed boundaries, and decisions written down where the next engineer will actually find them. Most systems do not fail because the technology aged — they fail because nobody recorded why it was built that way.

    Read the full answer

Read the code.

traceless-style is MIT licensed and public. It is the clearest picture of how we work.

Explore traceless-styleTalk to engineering
About Spark Golden Tech | Spark Golden Tech