AWS infrastructure for a healthcare SaaS platform
We built the AWS infrastructure of a US healthcare platform (SaaS) from scratch. The app runs on Elastic Beanstalk with Nginx.
- Trust and credibility
- Supervised
- High
Case studies and how we work
The case studies show how we make decisions on website and platform projects, from projects we delivered without naming the client to our own products. Each one explains the thinking and the outcome.
If you are choosing a partner for a website or a platform, this is where you can compare approaches before you talk to us. Filter the cases by industry or challenge, read the one that looks like your situation and, at the end, tell us about your project.
All case studies
You will find real projects we delivered, without the client's name, and our own products, with their names.
11 case studies
Planner: from specification to app
Planner is our own tool that turns detailed specifications into an application without supervision. For every feature the test is written first, the result is checked in the browser against the design, and a quality gate decides what moves on.
- Unclear structure
- Product evaluation
- High
Clinic website: a structure for trust and clarity
A clinic's website earns trust when it explains services, specialties and what happens from the first contact in plain, accurate words, and shows clearly how to book.
- Trust and credibility
- High-trust
- Intermediate
A SaaS website that explains the product
The website of a SaaS platform makes the product clear when the content is split by audience and depth, with use cases placed before the feature list.
- Product understanding
- Product evaluation
- Intermediate
A website for a B2B consulting firm
A consulting firm's website works when every visitor first finds a short explanation of what the firm does, then the details.
- Stakeholder alignment
- Multi-stakeholder
- Intermediate
A website for a bank or insurance company
For a bank or insurance company, which a supervisory authority oversees, a website works better when every page has an owner, the terms are the same everywhere and the navigation never changes.
- Accountability
- Supervised
- High
What are these case studies?
When a case is a real project or one of our own products, the label shows on its card and on its page.
Real project, no name. A project we delivered. The client's name, the domain and anything that could identify them stay confidential.
Our own product. Something we built for ourselves, such as our design tool or our content system. Here we write the real name, because it is ours.
How do you read a case?
Each case explains our thinking. It answers the same seven questions, in the same order: what the situation was, what the problem was, what limited the options, which common mistakes we avoid, which approach we took, which decisions mattered and what result to expect.
Because the order is always the same, you can compare two cases and see how the needs of a clinic differ from those of a software product. Start with the constraints and the key decisions. That is where our way of working shows best.
Which cases are there?
You can filter by industry, type of problem, decision environment or complexity. A few places to start:
Healthcare clinic: structure, trust and clarity, about how a patient quickly finds the right information.
SaaS platform: structure and product understanding, about a product that the visitor must understand before signing up.
AWS security and infrastructure for a healthcare SaaS platform in the US, a real project with no client name.
Planner: from written specification to application, our own tool, shown under its own name.
Kind | Is a name given? | The result is described as |
|---|---|---|
Real project | No | What was set up |
Our own product | Yes | What it does and how it is checked |
What do all of them have in common?
Structure comes before design. The navigation is predictable, so the visitor finds their way at once. The pages are written so that anyone who has to explain a decision to colleagues can find the answer and pass it on. At handover, your website is online, with access and documentation.
The same principles apply in different ways to a law firm, a clinic or a software company. That is why all the cases have the same format.
Why do we present the cases like this?
When you choose a partner, you want to see how a team thinks, not only what it delivers. A case that shows the constraints, the mistakes that were avoided and the choices that were made shows you how we would handle your situation.
It also lets us be honest. Where a result depends on your market, your content and your decisions, we say so clearly instead of giving a number.
Case studies and how we work Frequently asked questions
Are the case studies about real clients?
Some are, and the page of each case says so. A real project is one we delivered, shown without any detail that identifies the client. Our own products are named, because they belong to us. The others explain how we work in situations we meet often, and they do not name any client.
Why don't you show the clients' websites?
A name or a screenshot would reveal who the client is. Many of our clients work in fields where discretion matters. So we explain the thinking in detail and protect their identity.
Do the cases show traffic or sales?
The cases describe the result in clarity and ease of use. Traffic and sales depend on many factors outside the website, so we do not give such numbers. The number we guarantee is the score of the speed guarantee, which you can also measure yourself.
How do I find the case that fits me?
Compare your own constraints with the section that describes what limited the options. If they look alike, the rest probably applies too. If you are not sure, tell us about your project and we will suggest the closest case.
Next step: Case studies and how we work
Start your project
Send a project request, or check your current website for free. We read every message ourselves.