IT company · sowhatstrategyhub.com
SO WHAT STRATEGY
We design and build software, cloud platforms and data systems — and we start every piece of work with the same question: so what does this change for the business?
Fig. 01 — Infrastructure as architecture
02Positioning
Technology is only useful when it answers a question someone actually has.
Many software projects fail not because the code is poor, but because nobody agreed on what problem it was meant to solve. We work from the decision backwards: what needs to be known, done or automated, and what system makes that possible.
That perspective shapes how we scope, which tools we choose and what we decline to build. Fewer moving parts, clearer ownership, measurable intent.
03Core capabilities
Six disciplines, one line of reasoning.
- 01
Software engineering
- 02
Cloud infrastructure
- 03
Data & automation
- 04
Product design
- 05
Systems integration
- 06
Technology consulting
04Software engineering
Software built to be read, changed and run.
We write web applications, internal tools, APIs and back-end services with maintainability as a first-class requirement. That means typed interfaces, automated tests, documented decisions and code review on every change.
- — Web and service architecture
- — API design and implementation
- — Test automation and CI pipelines
05Cloud infrastructure & architecture
Infrastructure you can describe in a page.
We design cloud environments as code: reproducible, reviewable and sized to the workload. Networking, identity, observability and cost controls are part of the design rather than afterthoughts.
An illustrative scenario: a team running manually configured servers moves to declarative infrastructure, gaining repeatable environments for testing and a documented recovery path.
06Data systems & automation
Pipelines that turn records into decisions.
We build ingestion, transformation and reporting pipelines, and automate the repetitive work around them: reconciliations, exports, notifications, scheduled checks. Data quality rules are explicit and tested.
07Digital product design
Interfaces designed around the task, not the feature list.
We research how people actually work, map the flows that matter and prototype before committing to build. Design systems keep interfaces consistent as products grow.
Accessibility, legibility and performance are treated as design constraints from the first sketch.
08Technology strategy & consulting
Before building: decide what is worth building.
- Technology assessment
- A structured review of current systems, risks and technical debt, with prioritised recommendations.
- Architecture decisions
- Options compared on cost, risk, complexity and time, documented so the reasoning survives staff changes.
- Build, buy or integrate
- An honest comparison of custom development against existing products and services.
- Roadmapping
- Sequencing work so each step delivers something usable and reduces uncertainty for the next.
09Industries & challenges
Problems recur across sectors. So do good answers.
The challenges we are equipped to address appear in retail, logistics, professional services, finance operations, education and the public sector alike:
- Spreadsheets carrying business-critical processes
- Systems that cannot exchange data reliably
- Legacy applications nobody wants to touch
- Cloud costs that are hard to explain
- Reporting that arrives too late to act on
- Products that need to scale beyond a prototype
10Delivery process
Six steps. No surprises.
- 01
Discover
We study the business context, current systems, constraints and the decision the technology must support. The output is a written problem statement both sides agree on.
- 02
Frame
We define scope, architecture options and trade-offs, and agree on what will be delivered first and how progress will be measured.
- 03
Build
Work proceeds in short increments with working software reviewed regularly, so priorities can change based on evidence rather than assumptions.
- 04
Verify
Automated tests, code review, security checks and acceptance criteria are applied before anything is considered done.
- 05
Release
Deployments are planned, repeatable and reversible, with monitoring in place from the first day in production.
- 06
Evolve
After launch we review how the system is used, address issues and plan further improvements or a structured handover.
11Engineering principles & quality
Standards we hold every delivery to.
- Simplicity first
- The smallest design that solves the problem is usually the most reliable one.
- Tested by default
- Automated tests accompany production code; critical paths are covered before release.
- Secure by design
- Least-privilege access, managed secrets, dependency scanning and reviewed changes.
- Observable
- Logs, metrics and alerts are built in so problems are visible before users report them.
- Documented
- Architecture decisions and runbooks are written down and kept with the code.
- Transferable
- Everything we build should be operable by your team without us.
12Frequently asked questions
Questions, answered plainly.
What kind of work does SO WHAT STRATEGY take on?
Custom software, web applications, cloud architecture, systems integration, data engineering, product design and technology consulting — from an initial assessment to long-term maintenance.
Do you only work on new products?
No. A large share of technology work is improving what already exists: modernising legacy code, stabilising infrastructure or connecting systems that were never designed to talk to each other.
How does an engagement usually start?
With a short discovery phase. We review the context, the systems involved and the constraints, then propose a scope with explicit trade-offs before any build work begins.
Who owns the code and documentation?
Ownership terms are agreed in writing for each engagement. Our default approach is to deliver source code, infrastructure definitions and documentation that your team can operate independently.
Can you work alongside our internal team?
Yes. We can lead delivery, embed with an existing team, or act as an architectural reviewer, depending on what the situation requires.
How do we get in touch?
Send a short description of your situation to [email protected]. The contacts page lists the details that help us respond usefully.
13Closing statement
Every system should earn its so what.
If you have a technology question that matters to your business — a system to build, fix, connect or rethink — describe it in a few sentences and send it to us by email.