Technology
Engineering Decisions Based on the Product
The right technology depends on the workflow, users, data, security requirements, integration environment, deployment model, and expected lifetime of the software.
We select technology to support the operation, not to make the project appear more complicated.
What We Work With
Technology names are engineering choices, not partnerships or certifications. What matters is why one is selected over another for a given product.
Desktop
- Swift
- SwiftUI
- AppKit
- Native macOS development
- Windows application technologies where appropriate
Web
- TypeScript
- React
- Next.js
- Standards-based HTML and CSS
Backend
- Cloudflare Workers
- Node.js
- REST APIs
- Background jobs
- Authentication and authorization systems
Data
- SQLite
- PostgreSQL
- Structured local storage
- Transactional migrations
Cloud and Infrastructure
- Cloudflare
- AWS where appropriate
- Edge services
- Object storage
- Monitoring and diagnostics
Integrations
- OAuth
- eBay
- Shopify
- WooCommerce
- Stripe
- Marketplace and business APIs
Engineering topics
Native Application Engineering
Native software earns its place when responsiveness, local data, and operating-system integration matter more than universal reach.
A native desktop application gives an operator a dense, keyboard-driven workspace that keeps thousands of records responsive because the data is already on the machine. That matters for work measured in hours per day rather than minutes per week.
The cost is distribution and platform scope. Native software has to be built, signed, notarized, updated, and supported per platform, and features that depend on operating-system frameworks do not carry over automatically.
- Native (Swift, SwiftUI, AppKit)
- Best interaction performance and system integration; requires per-platform engineering and a release pipeline.
- Web application
- Immediate reach and instant updates; constrained by browser storage limits, file access, and background execution.
Web Application Engineering
Web platforms suit multi-user, multi-location, and customer-facing work where access and shared state matter more than local performance.
We build web applications with TypeScript and React, using server rendering for content and data that should be available immediately and correctly on first load.
Client-side JavaScript is added deliberately. Interfaces that only display information should not require a large runtime to become readable, and interactive surfaces should degrade predictably when a request fails.
- Server-rendered pages
- Fast first render, reliable indexing, less client JavaScript; needs a server or edge runtime.
- Client-side interactivity
- Richer editing and immediate feedback; increases bundle size and adds loading, error, and stale-state handling.
Cloud and Edge Systems
Edge runtimes are efficient for short, stateless, latency-sensitive work. Long-running or memory-heavy jobs belong elsewhere.
Cloudflare Workers suit request handling close to the user: authentication callbacks, webhooks, form endpoints, and lightweight API proxies with short execution times.
Work that needs long execution, large memory, native binaries, or persistent connections is better placed on a conventional server runtime. Choosing per workload avoids forcing an entire system into one execution model.
- Edge functions
- Low latency and simple scaling; execution time, memory, and runtime API limits apply.
- Long-running services
- Suitable for heavy processing and persistent work; more infrastructure to operate and monitor.
Data Architecture
The most consequential decision in operational software is which system owns each record.
Before choosing a database, we define ownership: which system is authoritative for a record, which systems hold a cached copy, and what happens when the two disagree. Without that decision, synchronization becomes guesswork.
SQLite is a strong fit for local-first desktop software, where a single application owns its own store. PostgreSQL fits shared, multi-user, and multi-tenant systems that need concurrent writes, richer constraints, and reporting.
Schema changes ship as versioned, transactional migrations so an interrupted upgrade leaves a consistent database rather than a partially migrated one.
- Local-first storage
- Fast, available offline, private by default; synchronization and conflict rules must be designed explicitly.
- Server-owned storage
- One authoritative copy and simpler reporting; depends on connectivity and needs access control at every boundary.
API Integrations
Integrations fail in predictable ways. Designing for those failures is most of the work.
A dependable integration accounts for rate limits, partial responses, duplicated webhook deliveries, out-of-order events, and provider-side schema changes.
Remote writes that change customer-visible records are ordered and idempotent, so a retry corrects an outcome instead of duplicating it. Failures are surfaced to the operator with enough context to act on.
- Webhook-driven sync
- Near real-time updates; requires signature verification, replay handling, and a reconciliation path for missed events.
- Scheduled reconciliation
- Simple and self-correcting; introduces delay and additional API volume.
Local-First Software
Local-first means the user’s own data lives on their machine and remains usable without a network round trip.
For high-volume operational work, local ownership removes latency from every interaction and keeps working data available when a connection is not.
It also raises questions that must be answered up front: what is backed up, what is synchronized, what happens on a second machine, and what is authoritative when local and remote records differ.
- Local ownership of working data
- Fast and private; backup, portability, and sync rules must be designed.
- Remote ownership
- Simple multi-device access; every interaction depends on the network.
Multi-Tenant SaaS Systems
Tenant isolation is a data-model decision made before the first customer, not a setting adjusted afterwards.
Every query in a multi-tenant system must be scoped to an organization, and that scoping belongs in a layer that cannot be bypassed by a new feature written later.
Roles, plan limits, and usage accounting are enforced server-side. The interface reflects entitlements; it does not define them.
- Shared schema with tenant scoping
- Efficient to operate and migrate; isolation depends on disciplined query construction and tests.
- Isolated databases per tenant
- Strong separation for demanding requirements; higher operational and migration overhead.
Monitoring and Diagnostics
When an operator reports that something did not sync, the system should be able to answer why.
Structured logs, request identifiers, and integration outcome records make individual failures traceable without collecting more personal data than the diagnosis requires.
Alerting focuses on conditions a person can act on — repeated authorization failures, sustained error rates, stalled jobs — rather than volume for its own sake.
- Verbose logging
- Faster diagnosis; increases storage cost and the amount of data that must be governed and retained responsibly.
- Minimal logging
- Smaller data footprint; harder to reconstruct what happened during an incident.
Testing and Release Verification
Tests concentrate where a defect would be expensive: business rules, data migrations, and integration boundaries.
Automated tests cover the logic that decides what a system does. Migrations are tested against realistic data, because a schema change that fails halfway through is among the costliest failures in operational software.
Releases are staged, verified against a defined checklist, and reversible. A release nobody can roll back is a release nobody can safely make.
- Broad end-to-end coverage
- High confidence in real flows; slower to run and more maintenance.
- Targeted unit and integration tests
- Fast feedback on the rules that matter; needs deliberate choices about what is left uncovered.
Accessibility
Operational software is used all day, often quickly, and sometimes with assistive technology. Accessible design is a usability requirement.
We build against WCAG 2.2 AA: semantic structure, complete keyboard operation, visible focus, labelled controls, sufficient contrast, and status changes that are announced rather than only shown.
Reduced-motion preferences are respected, and no status is communicated by color alone.
- Standard, semantic controls
- Accessible and predictable by default; less visual novelty in the interface.
- Custom interactive components
- Specialized interactions become possible; keyboard, focus, and announcement behavior must be implemented and tested deliberately.
Privacy and Security
Collect what the workflow needs, protect it at every boundary, and keep it no longer than required.
Secrets live in server-side configuration, never in client bundles or repositories. Transport is HTTPS only, and sensitive operations are performed by services the client cannot impersonate.
Data retention, access control, audit requirements, and regulatory obligations are identified during discovery, because they change the architecture rather than the finishing touches.
- Broad data collection
- More analysis is possible later; increases exposure, retention duties, and compliance scope.
- Minimal data collection
- Lower risk and simpler obligations; some questions cannot be answered retrospectively.
Engineering statement
We select technology to support the operation, not to make the project appear more complicated.
The Right Stack Depends on the Operation
Before recommending a technology, we need to understand the workflow, the data, the users, and what the software has to keep doing in three years. Tell us about the operation and we will explain the tradeoffs that apply to it.