Skip to content

Case Studies

Real software problems.
Real engineering solutions.

These are representative real-world problems we’ve worked through — from enterprise systems to growing software products. Each story shows the challenge, the constraints, the technical approach, and the result. Some details are generalized to protect the organizations and systems involved.

Let’s Talk Discuss a similar challenge.
Different problems. A practical conversation.
  1. Understand real problems
  2. Make practical decisions
  3. Engineer the solution
  4. Validate useful results

Same problems.
Different solutions.

Featured Case Studies

Every system is different, but the discipline is consistent: understand the real problem, work within the constraints, make practical decisions, and deliver something that works in production.

Better performance. More capacity.

Enterprise healthcare software

Production SQL Server performance and API capacity were limiting an important enterprise application.

We identified the real bottlenecks in the application and data layers, then tuned queries, indexes, and data access instead of assuming more hardware was the answer.

Better engineering before more infrastructure.

Software troubleshooting and performance tuning

View the engineering story

The problem

Production SQL Server performance and API capacity were limiting an important enterprise application.

The decision

We identified the real bottlenecks in the application and data layers, then tuned queries, indexes, and data access instead of assuming more hardware was the answer.

The constraints

  • An important application already operating in production
  • Capacity limited by application and data-layer bottlenecks
  • Improve performance without additional hardware

The engineering

  • SQL Server analysis
  • Query tuning
  • Execution-plan analysis
  • Indexing
  • Data-access improvements
  • API/application optimization
  • Identifying real bottlenecks rather than assuming infrastructure was the answer

The result

  • 35–60% SQL performance improvement
  • Approximately 40% greater concurrent API capacity without additional hardware

What made the difference

Better engineering before more infrastructure.

Modernizing without stopping the business.

Long-lived enterprise .NET platform

Years of business rules, integrations, data behavior, and operational knowledge made a full rewrite unnecessarily risky.

We modernized incrementally, preserving working business capability while improving architecture and introducing newer capabilities where they created value.

Modernization can be a direction, not a demolition project.

Ongoing engineering and .NET modernization

View the engineering story

The problem

Years of business rules, integrations, data behavior, and operational knowledge made a full rewrite unnecessarily risky.

The decision

We modernized incrementally, preserving working business capability while improving architecture and introducing newer capabilities where they created value.

The constraints

  • Keep production software usable
  • Preserve existing business rules and integration behavior
  • Retain the operational knowledge embedded in the application

The engineering

  • Preserve working business capability
  • Modernize incrementally
  • Improve architecture where it creates value
  • Update frameworks/components over time
  • Introduce modern APIs or web capabilities where appropriate
  • Reduce risk without forcing a disruptive big-bang replacement
  • Keep production software usable while modernization proceeds

The result

  • Reduced modernization risk
  • Preserved working business logic
  • Improved maintainability
  • Moved architecture forward incrementally

What made the difference

Modernization can be a direction, not a demolition project.

Measuring actual product use.

Subscription education platform

Page views and generic analytics could not show whether educators were actually using the product.

We separated successful product use from page loads, with account-aware identity, event deduplication, and funnels based on real activity.

Measure what the customer actually did — not merely what loaded.

Targeted software engineering projects

View the engineering story

The problem

Page views and generic analytics could not show whether educators were actually using the product.

The decision

We separated successful product use from page loads, with account-aware identity, event deduplication, and funnels based on real activity.

The constraints

  • Distinguish landing-page visits from actual successful product usage
  • Separate meaningful interactions from page loads
  • Recognize different account/audience types
  • Handle duplicate client/server events
  • Separate legitimate users from bots, admin traffic, and infrastructure noise

The engineering

  • Successful game/application loads as meaningful usage events
  • Authenticated usage
  • Account-aware identity rules
  • Event deduplication
  • Range-wide unique usage
  • Ordered funnels based on real event progression
  • Separating page loads from meaningful interactions
  • Excluding inappropriate traffic
  • Preserving useful PDF/resource activity where relevant

The result

  • More accurate usage reporting
  • Better funnel integrity
  • Reduced duplicate-event noise
  • More meaningful product decisions

What made the difference

Measure what the customer actually did — not merely what loaded.

Changing access without breaking the subscription model.

Subscription education platform

Customers needed to begin with one product package and unlock an additional package during the same trial.

We changed the entitlement cleanly while preserving trial dates, billing and renewal data, order history, and the rest of the subscription lifecycle.

Product flexibility without compromising entitlement integrity.

Custom business software development

View the engineering story

The problem

Customers needed to begin with one product package and unlock an additional package during the same trial.

The decision

We changed the entitlement cleanly while preserving trial dates, billing and renewal data, order history, and the rest of the subscription lifecycle.

The constraints

  • Access controlled by subscription entitlement rather than role
  • Authenticated upgrade action
  • Anti-forgery protection
  • Idempotent behavior
  • Preserve existing trial start date
  • Preserve existing trial end date
  • Do not silently extend the trial
  • Preserve billing and renewal data
  • Preserve order/payment history
  • Leave existing upgraded/premium trials intact

The engineering

  • Change the entitlement cleanly while preserving the rest of the subscription lifecycle.
  • Handle repeat requests safely without repeating the upgrade.

The result

  • Self-service upgrade path
  • Trial dates preserved
  • Billing history preserved
  • Subscription integrity maintained
  • Repeat requests handled safely

What made the difference

Product flexibility without compromising entitlement integrity.

More real-world problems

A range of challenges. A consistent focus.

These are some of the other kinds of software problems we’ve worked through over the years.

Authentication & authorization

Centralized authentication, RBAC, authorization design, secure APIs, identity integration, and incremental adoption.

System integrations

REST APIs, third-party/vendor systems, authentication, data movement, synchronization, and failure handling.

Azure & cloud delivery

Azure infrastructure, CI/CD, deployment, monitoring, application configuration, and operational security.

Production troubleshooting

Difficult-to-reproduce problems, performance failures, integration errors, production-only behavior, and root-cause analysis.

Technical debt

Identify the debt that actually matters. Targeted refactoring and incremental cleanup reduce risk without unnecessary rewrites.

AI-assisted development

AI-generated code review, architecture review, refactoring, production hardening, and correcting generated implementation problems.

Application modernization

Legacy framework updates, architecture improvements, UI modernization, and incremental replacement that preserves business behavior.

Subscription & billing

Entitlements, trials, upgrades, package transitions, and business-rule-heavy subscription workflows.

Analytics & reporting

Actual-use analytics, funnels, meaningful interactions, account-aware reporting, and data integrity.

Application rescue

Stalled work, brittle software, difficult technical blockers, and finishing or stabilizing critical pieces.

How we approach the work

From problem to practical solution.

Every situation is different, but the engineering discipline is consistent.

  1. 1

    Understand

    Learn the real problem, constraints, users, business goals, and environment.

  2. 2

    Analyze

    Dig into the application, code, data, architecture, integrations, and production behavior.

  3. 3

    Decide

    Choose the smallest practical approach that solves the actual problem.

  4. 4

    Implement

    Make the change, integrate it, validate it, and deploy carefully.

  5. 5

    Measure

    Confirm that the result solves the problem and identify what was learned.

Real problems. Practical engineering. Results that matter.

What the work demonstrates

The solution matters.
So does how you arrive at it.

Across different systems and industries, the same engineering habits keep showing up.

Good engineering is as much about judgment as implementation.

Understand the business context

Technical decisions make more sense when the business constraints are understood first.

Ask the right technical questions

The visible symptom is not always the real problem.

Recommend practical solutions

The goal is not the most interesting architecture. It is the right solution for the situation.

Deliver something that lasts

A solution should work in production, fit the system around it, and be maintainable by the people responsible for it.

It’s about
results that
matter.

Have a similar challenge?

Let’s talk about what’s possible.

Every system is different. Tell us about your situation and we’ll discuss how our experience may apply — without forcing your problem into somebody else’s case study.

Let’s Talk A practical conversation.
No pressure. Just real engineering discussion.
  • Discuss your specific situation
  • Get an experienced perspective
  • Explore practical options
  • Focus on what makes sense for your business