Many business systems work best as one application that is deployed, upgraded and supported as a whole. Sphere 10 builds that application in .NET with clear internal modules for areas such as orders, billing, scheduling and inventory, so it stays maintainable as it grows. We also modernise existing systems without losing the behaviour your business relies on.
What we build
Organise around your business. Each module owns its rules and its data, and other modules reach it through a defined interface instead of reading its tables directly.
Keep changes consistent. Related database changes commit together. Slow work, such as calls to another system, runs in the background where it can be inspected, cancelled and retried.
Modernise one journey at a time. We take a complete user journey, record how it behaves today, including the edge cases, then rebuild it with compatible data and screens before touching the next one.
Choose a fitting stack. We use ASP.NET Core with Blazor or MVC on SQL Server or PostgreSQL, with browser or Windows interfaces.
Business modules expose contracts within one host and commit through deliberate local transaction boundaries.
What you receive
Tested business workflows across modules, including rejection and failure paths.
Source code, build instructions and database migration scripts.
Logs and health signals that identify the affected business operation.
Module contracts and a prioritised maintenance backlog.
How we engage
We start by agreeing business responsibilities and the data each module owns, before any project structure is created. Acceptance covers the integrated release: permissions, cross-module workflows, reports, background work and recovery, under realistic data volumes and simultaneous users. We rehearse installation, upgrade and restoration with you, so your team knows how to deploy a new version and restore service.
Technologies & Integration
ASP.NET Core application architecture — Compose a single deployable application with internal capability boundaries, entry points and owned dependencies.
EF Core — Implement explicit persistence units of work and selected-provider transaction behaviour inside application operations.
NHibernate — Configure mappings, session lifetime, concurrency and transaction ownership where NHibernate is the selected ORM.
.NET Generic Host — Compose dependency injection, configuration, logging and startup/shutdown for the application and hosted work.
OpenTelemetry .NET — Correlate requests, module operations and database work while measuring the delivered system as one application.
Messages With Ownership|Reliable Work Across Hosts
When work passes between systems, such as an order moving to fulfilment, a document entering processing or a record going to your ERP or CRM, it must arrive once and finish properly even when something fails along the way. Sphere 10 builds message-driven applications in which every piece of work is tracked from the original database change to the completed result.
What we do
Pick the broker for the job. RabbitMQ, Apache Kafka, Azure Service Bus and Amazon SQS route and order work differently. We choose and configure one around your delivery and ordering needs.
Define the messages. Each command has one responsible handler, and each message carries an identity, a version and compatibility rules, so participating applications can change without breaking each other.
Prevent lost and repeated work. A business change and its outgoing message are recorded together. Receivers recognise a message they have already handled, so a redelivery does not repeat a payment or reservation.
Make the backlog manageable. Your operators see how old the waiting work is, what failed and why, and can replay it under control.
The producer commits an outbox record; consumers commit an idempotent business result before acknowledging delivery.
What you receive
Working producer and consumer services with their source and tests.
Message contracts and broker configuration.
Dashboards showing backlog, throughput and failed business operations.
Replay and recovery procedures your team has seen exercised.
How we engage
Design settles what must be durably recorded before a message counts as handled, and how the same message is recognised when it arrives again. At acceptance we deliberately interrupt the path between each step, restart the services and check that work resumes without duplication. Load tests include a slow consumer and a temporary outage of a dependency.
Technologies & Integration
RabbitMQ confirms and acknowledgements — Separate publisher confirmation from consumer acknowledgement and commit the business result before completing delivery.
Apache Kafka — Design topics, partition keys, consumer groups, offsets and retention around replay and ordering requirements.
Azure Service Bus — Configure queues/topics, subscriptions, message locks and the selected dead-letter and duplicate-handling policy.
Amazon SQS — Define visibility, consumer deletion, redrive and standard/FIFO queue behaviour for the actual workflow.
OpenTelemetry .NET — Carry correlation across producer, broker and consumer work and expose useful latency and failure evidence.
Slow screens, long imports and reports that time out cost your staff time and often have causes outside the obvious query. Sphere 10 tunes SQL Server, PostgreSQL, MySQL and SQLite databases together with the application that uses them, and shows the improvement with measurements taken before and after on the same workload.
What we do
Measure before changing anything. We record a representative workload with your data volumes and concurrent users, then find where the time goes in the database, the application and the network between them.
Fix the real cause. A slow screen may need a narrower query, an import may need better batching, and a report may need a different way of aggregating or storing its data.
Weigh reads against writes. An index that speeds one query adds work to every update. We test the workload as a whole, including storage growth and maintenance.
Engineer imports and concurrency. Bulk loading, batch sizes, restart points and duplicate handling are tuned together, and simultaneous readers and writers are tested under realistic operations.
A repeatable workload produces comparable application, query-plan, correctness and tail-latency evidence before and after a targeted change.
What you receive
Query, index and application changes with the reason for each.
Before and after measurements under stated conditions.
Repeatable benchmarks and correctness checks.
Deployment and rollback instructions, and monitoring that detects later regressions.
How we engage
Tell us which operations matter, how much data they touch and how many people use them at once. We rerun the same workload against the changed system and compare results as well as timing: totals, ordering, duplicates and transactional behaviour. Our own BlockchainSQL product, which loads Bitcoin data for SQL analysis, is a working reference for this kind of ingestion and query work.
Technologies & Integration
SQL Server Query Store — Compare plan and runtime history for the measured workload, then verify targeted query or index changes.
PostgreSQL EXPLAIN — Inspect estimates and execution work, selecting ANALYZE and buffer evidence deliberately for the query under test.
MySQL optimisation — Review query plans, indexing and engine behaviour against the application's actual read/write pattern.
EF Core — Check generated commands, loading boundaries, transaction size and concurrency together with the selected database provider.
Npgsql COPY — Build a measured PostgreSQL bulk-import/export path with explicit completion, transaction and restart behaviour.
Cloud With Clear Ownership|Deploy, Operate, Recover
Moving to the cloud removes some infrastructure work, but your application still needs a sound data model, controlled access, repeatable releases and a recovery plan that has been tried. Sphere 10 delivers .NET applications on Azure or AWS together with the environment around them, so your team can run the service without depending on undocumented setup.
What we do
Fit the hosting to the workload. We map each part of the application to what it needs, using Azure App Service, Azure Container Apps or AWS ECS, with virtual machines or Kubernetes where they suit better.
Keep data and work durable. Records, files and queued work live in managed databases, storage and queues, so replacing a running instance loses nothing.
Automate releases. The environment is defined in code and each release is a versioned package with its matching database migration, rollout checks and rollback conditions.
Show service health. Monitoring separates failed requests, overloaded workers and unavailable dependencies, and each alert points to someone responsible for the response.
Identity, runtime and durable data connect to a repeatable release process, observable health and tested recovery.
What you receive
A working cloud environment with identity, configuration and secrets set up.
Source code and infrastructure definitions.
Dashboards, alerts and a tested recovery procedure.
Runbooks, access responsibilities and an operational maintenance plan.
How we engage
We first agree your users, traffic, data ownership, recovery objectives and who operates what. Those answers decide the cloud components, not the reverse. Before handover we run a realistic deployment, take a dependency offline, interrupt a worker and restore from backup, then review cost and capacity against your intended operating profile.
Technologies & Integration
Azure App Service — Deliver the selected managed .NET web host with application settings, deployment and operating checks.
Azure Container Apps — Configure container applications/jobs and the selected ingress, scale and environment boundary.
Amazon ECS — Deploy versioned tasks and services with the agreed Fargate or EC2 capacity and persistence requirements.
Amazon RDS — Select and operate a managed relational database with explicit connectivity, backup and recovery ownership.
OpenTelemetry .NET — Connect cloud request, dependency and background-work evidence to the business operation and support runbook.
Services With Clear Owners|Independent Change, Tested
Microservices suit an organisation that needs to change and release parts of a system independently. Splitting code into separate processes is only the deployment step. Sphere 10 builds services that each own a business capability, its data and its published interface, and demonstrates that one can be released or fail without breaking the others.
What we build
Draw boundaries with business meaning. A service owns records and rules that belong together. We extract one capability at a time from an existing application, around a complete and visible user outcome.
Publish dependable interfaces. Services communicate through versioned REST or gRPC APIs and durable messages, never by updating each other's tables.
Finish work across services. Where several services must complete one operation, progress is recorded, and there are defined steps to compensate or reconcile after a partial failure.
Run it as one system. Services are packaged in containers and deployed on Kubernetes with health checks and staged rollouts. A single business operation can be traced across every service it touches.
Orders and billing retain separate data ownership while messages and workflow state coordinate a traceable business outcome.
What you receive
Deployable services with source, contracts and deployment configuration.
Contract tests that show compatibility with current consumers.
Operational dashboards and a service dependency map.
Recovery runbooks and incident procedures.
How we engage
Design names an owner for each service: the capability, the records, the public interface and the operating responsibility. Acceptance releases one service while its consumers stay on the previous version. We then stop a dependency, delay a message, repeat a request and restart a participant mid-workflow, and confirm that progress stays explainable and nothing happens twice.
Technologies & Integration
gRPC on .NET — Define typed service contracts, deadlines and compatibility alongside the selected REST/OpenAPI endpoints.
RabbitMQ — Configure durable message publication/consumption and verify the application's outbox, acknowledgement and idempotency boundaries.
Apache Kafka — Use explicit event schemas, partition keys, consumer groups and replay/offset ownership for the selected workflow.
Kubernetes Deployments — Package independently released services with rollout, readiness, capacity and configuration requirements.
Dapr pub/sub — Integrate the selected messaging abstraction with explicit component configuration and application completion rules.
The MERN stack combines a React user interface, Express APIs, Node.js processing and a MongoDB database. Sphere 10 builds customer portals, operational dashboards, marketplaces and workflow applications on it, with the full path from a user's action to a saved business result designed and tested.
What we build
Screens shaped around the task. React forms handle validation, loading, conflicts and errors clearly, and work with a keyboard and on small screens.
A data model that fits the work. MongoDB documents and indexes follow how your application reads and updates its data, and are measured with representative records.
A server that checks everything. The API validates incoming data and enforces permissions itself. It does not rely on the browser to do so.
Background work that survives restarts. Heavy processing moves off the interactive path. Payments, notifications and imports record their outcome before any retry.
Connection to your .NET systems. Where you also run .NET services, we build a versioned API or messaging link, and each side keeps ownership of its own records.
React, Express, MongoDB and Node workers form one workflow, with a deliberate contract where .NET business systems participate.
What you receive
A complete MERN application with tested workflows.
Source code, environment configuration and build instructions.
Database indexes, migration procedures and operational monitoring.
Integration tests and support runbooks.
How we engage
We begin with one real user task and carry it through the screen, the API, the database and its visible completion. That slice sets the pattern for the rest. Acceptance runs the workflow end to end, including unauthorised requests, invalid data, a failed dependency and restarted jobs, with realistic document sizes and concurrent users. We rehearse deployment, configuration changes, backup and restoration with your team.
Technologies & Integration
MongoDB data modelling — Select document boundaries, indexes, validation and transaction scope around the actual read/write invariants.
Express middleware — Compose authentication, validation, routing and error handling into an explicit HTTP request pipeline.
React state — Separate component drafts, navigation state and authoritative query results with deliberate update and invalidation rules.
Node.js execution — Keep request work responsive and assign expensive or durable processing to the appropriate worker boundary.
TypeScript — Maintain typed application and API contracts while independently validating untrusted runtime input.
ASP.NET Core OpenAPI — Integrate an owned .NET business domain through versioned operations, errors and concurrency contracts.
Reports are only useful when people trust the figures. Sphere 10 builds data lakes and warehouses that bring your databases, business applications and files into one analytical platform, where every published number can be traced back to its source and rebuilt on demand.
What we do
Choose the platform. We work with Microsoft Fabric, Azure Data Factory, Databricks, Snowflake and AWS Athena, selected to suit your data.
Keep the source evidence. Raw records are retained with their origin and arrival time, so a transformation can be rerun and investigated later.
Build repeatable pipelines. Each run records what it accepted and what it rejected. Invalid records are set aside for correction. Duplicates, partial batches and late updates are tested.
Model for agreed meaning. We settle with you what one row represents and how each measure is calculated before building Power BI or other reporting on top.
Reconcile the numbers. Totals and record counts are checked back to the source before a dataset is accepted.
Retained source evidence moves through validation and business modelling, with reconciliation supporting reproducible results.
What you receive
Pipeline source code and orchestration configuration.
Dataset definitions, quality rules and data lineage.
Operational dashboards for the pipeline.
Procedures for investigating a failed batch, correcting rejected records and rebuilding a dataset.
How we engage
Design identifies the authoritative source and owner of each dataset, and the access and retention rules for sensitive fields. At acceptance we rebuild selected results from their source and compare counts, totals and business examples with what you expect. We also interrupt a load, rerun a section of data and apply a source format change to check recovery. Our BlockchainSQL product is a working reference for turning specialised source records into SQL-ready data.
Technologies & Integration
Microsoft Fabric lakehouse — Select OneLake/lakehouse tables and ownership boundaries for engineering and analytical consumption.
Azure Data Factory — Orchestrate connector extraction, dependencies and identifiable pipeline runs with explicit rerun and failure handling.
Databricks Delta Lake — Implement table transformations and merge/update behaviour with schema, batch and transaction history understood.
Power BI star-schema modelling — Define fact grain, dimensions, relationships and business measures that reconcile to the source records.
Apache Parquet — Choose a columnar interchange/storage layout with partition, schema and reader compatibility checked for the selected tools.
Your Site, Working Systems|Install, Update, Recover
Some systems have to run on your own servers, beside your own identity, storage and network. Sphere 10 delivers installed .NET applications for Windows Server and Linux, packaged so that your own team can install, update and restore them, including at sites with controlled internet access.
What we do
Design for the actual site. We map your operating systems, accounts, network paths, storage and support access before choosing how the system is deployed.
Integrate with your identity. The application works with Active Directory or your chosen identity provider, with separate responsibilities for operators, administrators and service accounts.
Protect your data. SQL Server, PostgreSQL or SQLite is chosen to suit the workload. Business records and uploaded files are kept apart from the replaceable application package.
Handle network loss. We define what keeps working when an outside connection drops, and queued work resumes when it returns.
Make maintenance practical. Operators get a version inventory, a configuration health check, diagnostics and a package-transfer procedure for restricted sites.
Local identity, application and data are delivered with installation, operator evidence and a complete restore package.
What you receive
Versioned installation packages, with source code or agreed distribution files.
Installation instructions and database migration scripts.
Runbooks for updates, log retention, capacity and secrets.
A restore package and the evidence from the acceptance exercises.
How we engage
Acceptance takes place on the class of server you will use. We rehearse a clean installation and a version upgrade, restart the service, recover interrupted work and restore a backup into a clean installation. The restore test includes the configuration and keys needed to make the recovered records usable. Our Local Notion product, which keeps content on local storage and produces offline publications, is a working reference for this approach.
Technologies & Integration
.NET Windows Services — Package managed background work with the service account, runtime, restart and operating checks required by the site.
Linux systemd — Deliver the installed process identity, execution context, supervision and shutdown behaviour.
SQL Server backup and restore — Own the local database recovery model, retained backup chain and complete restore procedure.
SQLite concurrency — Select embedded connection, write/read and checkpoint behaviour with an engine-supported backup method.
Local Notion — Reference an owned .NET product with locally retained source/media and reproducible offline HTML/publication outputs.
