We are a product company that builds for others.
Pulsar Digital, based in Charlotte, NC, is a software engineering and product company. We design, develop, launch, and scale custom applications, SaaS platforms, mobile products, and automation systems — with the same engineering discipline we use to build and operate our own products.
Engineering-first, product-minded
We think in systems, ship with care, and stay involved after launch.
Product-first discovery
We do not start with tickets. We start with decisions: what a product owns, who its tenants are, what success looks like, and what would be expensive to reverse after customer data exists.
Security by design
Tenant scope, authorization, audit evidence, and failure modes are part of the architecture from the first commit. We do not retrofit security after a breach or after launch.
Capability-gated delivery
We ship when acceptance gates pass, not when a calendar says so. Every gate has defined evidence and an explicit go / no-go posture.
Long-term partnership
We build systems we are happy to hand over, and we stay involved to scale, harden, extend, and operate them with the people who use them.
How we operate
A small team with the discipline of a much larger one.
Written decisions, not assumptions
Every significant product boundary lives in a decision log: tenancy, identity, authorization, record lifecycle, payment scope, and what the MVP explicitly excludes. This keeps the whole team aligned and makes every later trade-off traceable.
Threat models before test plans
We model trust boundaries, abuse cases, and cross-tenant attack paths while the product is still on paper. Controls are designed in, not bolted on.
State machines, not ad hoc flows
Requests, records, payments, claims, and invitations have explicit lifecycles. Draft, review, approve, lock, amend, hold, retry, and cancel are first-class concepts, not afterthoughts.
Proofs, not promises
We do not claim production readiness until we have exercised tenant isolation, atomic failure, worker reauthorization, provider inbox handling, file quarantine, migration rollback, and isolated restore.
How we build
Architecture that survives growth, provider changes, and real failure.
Strict, typed foundations
We use strict TypeScript across the stack with explicit validation at every untrusted boundary. Unreviewed JavaScript escape hatches are not part of our workflow.
Modular monoliths first
Web, API, worker, database, object storage, and provider adapters are separated by contract, not by premature network calls. A single repository and one authoritative database keep the product coherent and testable.
Defense in depth
Application authorization plus forced PostgreSQL row-level security, non-owner runtime roles, transaction-scoped tenant context, and query invariants on every read, write, list, count, search, and join.
Atomic evidence
A business transition, its immutable audit record, and any required external-effect obligation commit in one transaction. If any part cannot commit, the action fails.
Provider-neutral contracts
Domain logic never depends on a specific identity, email, payment, storage, or hosting vendor. We build internal ports and replaceable adapters so the product survives a provider change.
Durable obligations and reconciliation
External effects become explicit, idempotent, queryable outbox obligations. Provider events enter a durable inbox with raw-body verification, deduplication, conservative ordering, and reconciliation before they affect state.
Trust, compliance, and correctness by default
We treat tenant isolation, record integrity, and financial correctness as architectural requirements, not after-the-fact certifications. Our products are designed for real regulatory, legal, and operational contexts.
What we mean by production-ready
Production is not a deploy button. It is the state where the product has passed the gates that matter for what it owns.
- 01Threat model and access matrix reviewed against the actual domain.
- 02Tenant isolation, RLS, and authorization paths tested with fault injection.
- 03Migrations, backups, and isolated restores rehearsed on a separate target.
- 04Critical workflows meet the agreed accessibility target through automated, keyboard, and assistive-technology checks.
- 05Payment, identity, email, storage, and backup providers pass contract acceptance without embedding vendor vocabulary as domain truth.
- 06Legal and specialist counsel review language, records, notices, and customer responsibilities where required.
Multi-tenancy with real isolation
Tenant scope is derived from trusted persisted resources, not from route values, headers, form fields, filenames, or provider metadata. Master and child tenants, shared managers, and shared payers never imply cross-tenant access.
Identity separated from authority
A valid login proves authentication only. Access requires current role assignments, relationships, delegation, MFA assurance, and approval evidence evaluated at the moment of each request.
Immutable audit and official records
Business, security, financial, and support actions produce append-only evidence. Locked records cannot be silently edited; corrections flow through linked, attributable amendments.
Dual control and least privilege
Sensitive financial actions require different initiator and approver identities, MFA, and explicit audit evidence. Support personnel have no standing tenant access; elevation is purpose-bound, time-bound, and separately approved.
Deployment that grows with the business
We scale infrastructure by evidence, not by defaulting to the most expensive platform.
Profile A — Local
Docker Compose and deterministic local substitutes. No paid external services required to develop, test, or reproduce trust boundaries.
Profile B — Private alpha/beta
One appropriately sized VPS with separate web, API, worker, and PostgreSQL containers. Cloudflare Tunnel, S3-compatible object storage, encrypted offsite backups, and no SLA claim until promotion gates pass.
Profile C — Managed growth
The same images on Render or an equivalent managed container platform, with managed PostgreSQL and independently scalable workers.
Profile D — Enterprise cloud
The same application boundaries on AWS ECS/RDS/S3 when contractual, security, procurement, or scale requirements justify the breadth.
Moving between profiles is an operational migration, not a domain rewrite. The same container images, database contracts, provider ports, and audit obligations move with the product.
We build and operate our own products
Pulsar is not a body shop. We build real, multi-tenant products with real users, real billing, real security boundaries, and real operational concerns. That experience shapes how we work with clients.
Why that matters for your project
We have faced the same decisions our clients face: how to model tenants, how to handle imports that cannot overwrite authoritative records, how to make payments reconcile, how to release a product without claiming availability we cannot guarantee, and how to keep a small team productive without cutting corners that become expensive later.
When you work with Pulsar, you get the judgment that comes from shipping, operating, and supporting products end to end.
Why a small team can out-engineer a large one
High leverage comes from clarity, not headcount.
Codex-assisted, human-approved
We use AI-assisted tooling for fast, consistent, constrained changes. Authorization, migration, provider, deployment, and recovery decisions still require human review.
Explicit over implicit
Every boundary, role, state, and exception is documented before it is implemented. The result is code that is easier to review, test, hand over, and scale.
Fewer moving parts
We do not add Kubernetes, Kafka, Redis, Elasticsearch, or microservices before measured needs justify them. A disciplined modular monolith beats a distributed mess.
Reliability by construction
Atomic commits, durable obligations, idempotent workers, provider inboxes, and bounded retries remove the categories of bugs that consume most engineering teams.
Let's build something real.
Whether you have a product idea, an existing platform, or a workflow that needs software, we should talk.