TESSELL
0→1, building a self-service Maintenance Center so customers control their own infrastructure updates
0→1, building a self-service Maintenance Center so customers control their own infrastructure updates
Team
2 Product owners
1 Product manager
3 Developers
Role
Design Research
Conceptualisation
Design
Testing
Major Clients
Equinor
AON
Levi’s
Citizen Bank
Aker BP
Duration
04 months,
02 phases
Overview
Tessell is a cloud database management platform that helps enterprises provision, manage, and operate databases across multiple cloud environments, giving teams a single place to handle everything from infrastructure to compliance, at scale.
Databases need regular maintenance: OS patches, DB patches, storage resizing. It's a recurring need, not a one-time task, and getting the timing wrong means real downtime for real businesses. At Tessell, this was entirely manual, run by support teams on behalf of customers. We built the Maintenance Center from scratch, giving customers direct control over when and how their systems get updated.
The problem
Before this project, maintenance scheduling happened over email and spreadsheets. Customers managing hundreds of servers would tell support teams when they wanted maintenance — and at that scale, human error was inevitable. Maintenance windows were sometimes missed entirely, or scheduled at the wrong time.
That mattered more than it sounds. A maintenance window means planned downtime — similar to a Mac OS update, where the system briefly goes offline to apply changes. Get the timing wrong, and a customer's business operations take the hit, not just an internal process.
01
01
Compliance Requirement
Compliance Requirement
Regular OS patching is essential to meet customer needs, but currently
it is infrequent as it is done manually
Regular OS patching is essential to meet customer needs, but currently
it is infrequent as it is done manually
02
02
Dependence on Support Teams
Dependence on Support Teams
We depend heavily on support teams to handle customer patching requests,
causing delays and dissatisfaction.
We depend heavily on support teams to handle customer patching requests,
causing delays and dissatisfaction.
03
03
Manual and inconsistent Patching
Manual and inconsistent Patching
OS patching for managed database services is mostly manual, inconsistent,
and lacks automation
OS patching for managed database services is mostly manual, inconsistent,
and lacks automation
04
04
Limited Visibility
Limited Visibility
Customers do not have adequate visibility into patch status and
compliance metrics.
Customers do not have adequate visibility into patch status and
compliance metrics.
Users
Before this project, maintenance scheduling happened over email and spreadsheets. Customers managing hundreds of servers would tell support teams when they wanted maintenance — and at that scale,
Primary User
Infrastructure Admins
Owns the platform itself, creating and maintaining virtualisation
infrastructure, managing compute, networks, and security, and deciding on
cloud migration targets.
They care about systems running efficiently, but have no visibility into the
individual database services running on top of their infrastructure.
Owns the platform itself, creating and maintaining virtualisation
infrastructure, managing compute, networks, and security, and deciding on
cloud migration targets.
They care about systems running efficiently, but have no visibility into the
individual database services running on top of their infrastructure.
Database Owners
Manages the database environment day to day, provisioning services, clones,
backups, and snapshots, while making sure everything runs within
compliance and SLAs.
Their world is the database layer, not the servers underneath it, so a
maintenance schedule set at the server level can affect them without
their knowledge.
Manages the database environment day to day, provisioning services, clones,
backups, and snapshots, while making sure everything runs within
compliance and SLAs.
Their world is the database layer, not the servers underneath it, so a
maintenance schedule set at the server level can affect them without
their knowledge.
The constraints that shaped the design
Infrastructure complexity
Infrastructure complexity
Multi-instance servers can depend on each other, OS patches need to stay consistent across them. Phase 1 scoped to dedicated and single-instance servers, with the system designed to scale into multi-instance support in Phase 2.
Multi-instance servers can depend on each other, OS patches need to stay consistent across them. Phase 1 scoped to dedicated and single-instance servers, with the system designed to scale into multi-instance support in Phase 2.
Patches don't behave the same way
Patches don't behave the same way
OS patches apply at server level (or service level, for dedicated servers); DB patches apply at service level. More maintenance types were already on the roadmap, exactly why "maintenance-centric" was the right call.
OS patches apply at server level (or service level, for dedicated servers); DB patches apply at service level. More maintenance types were already on the roadmap, exactly why "maintenance-centric" was the right call.
Two personas, two diff. blind spots
Two personas, two diff. blind spots
Infra admins manage servers but can't see individual services. Data owners manage services but can't see the servers underneath. A server-level schedule can cause downtime to a service a data owner cares about, without them ever setting it.
Infra admins manage servers but can't see individual services. Data owners manage services but can't see the servers underneath. A server-level schedule can cause downtime to a service a data owner cares about, without them ever setting it.
Making it Maintenance Centric
The first real question wasn't visual, it was conceptual: should this be update-centric, resource-centric, or maintenance-centric? That single decision would shape everything downstream, so I started with research rather than screens.
I mapped 5 core user journeys to understand how customers actually thought about this task, and looked at how direct and indirect competitors handled similar problems. No one had fully solved it, especially not for Tessell's specific infrastructure model, which supports multi-instance servers that other platforms don't.
That research is what led to "Maintenance Center" as the right framing, not an update tool, but a home for everything related to keeping infrastructure healthy.
Introducing Maintenance Center
A centralized, self-service experience to schedule, manage and track maintenance across database infrastructure.
Provisioning · User action Setting up maintenance
Touchpoint Provisioning
Setting maintenance preferences from day one
01 Configure maintenance preferences during provisioning
02 Choose a recurring cadence by day or date
03 Enable automatic OS patching from the start
Maintenance Center · User action Finding resources needing attention
Touchpoint Provisioning
Find what needs attention, faster
01 Identify resources without maintenance schedules
02 View resources with pending updates
03 Take contextual action to configure maintenance
Maintenance Center · User action Rolling out a patch
Touchpoint Provisioning
From available patches (updates) to scheduled activities
01 Schedule updates within preferred maintenance windows
02 Enable or modify automatic patching preferences
The design decisions behind the experience
01
Making complex scheduling feel simple
How global/default windows, custom windows, recurring cadence and scheduling controls were structured without overwhelming users.
02
Helping users act with confidence
Review and confirmation, affected resources, maintenance impact, permissions and clear feedback before applying changes.
03
Keeping everyone informed
Upcoming maintenance, notifications, status tracking and communication across infrastructure admins and database owners.
Introducing Fleets
A Fleet groups dependent resources under one schedule, simplifying maintenance and updates across multiple servers
As dependent, multi-instance servers entered the picture, a second clear intent emerged: customers don't think server-by-server, they think in groups. Many servers needed the same OS version and the same schedule simply because they depended on each other. Rather than bolting on a separate feature, I introduced "Fleet" — a named group of servers sharing one maintenance schedule — as an additional view layered onto the same underlying structure. The app now serves two intents cleanly: "show me what's happening across my resources," and "let me manage resources as logical groups."
There's more behind the final screens - happy to walk you through the full journey, iterations and decisions. Let's connect!
Testing & validation
Presented the prototype and concept directly to two real customers, Equinor and AON. They responded positively and understood the flow easily. Feedback was minor and specific, for instance, the maintenance schedule cadence originally only supported selecting by date, and customers wanted the option to select by day as well. These small configuration tweaks helped personalise the experience to how different customers actually think about recurring schedules. The feature is now in production and being rolled out.
Outcome & reflection
Maintenance Center is live and rolled out to customers. Reception has been strong, particularly from infra admins and data owners, who for the first time have direct visibility and control over maintenance schedules that directly affect their systems. Beyond existing customers, the feature has been pitched to AT&T as a prospect, and is actively helping close that deal. That's the kind of downstream impact that's easy to overlook in a portfolio, but it matters: good design moved a commercial conversation forward.
What made this project genuinely hard was the absence of reference points. Tessell supports multi-instance infrastructure that platforms like GCP or AWS don't, which meant there were no existing UX patterns to borrow from, no competitors who'd solved this before us. Everything had to be reasoned from first principles, understanding the customer, mapping the complexity, and figuring out what the system could actually support, all at the same time.
The other thing that stayed with me was the collaborative weight of a project at this scale. Multiple stakeholder reviews, cross-team alignment, pitching the concept at a leadership level, and then sitting with engineers at the end to make sure the experience wasn't compromised in implementation. That full arc, from blank canvas to production.
Let's build something thoughtful!
Let's build something thoughtful!
Portfolio is just a glimpse - let’s connect for the full story
Portfolio is just a glimpse - let’s connect for the full story
Made with ♥️ . © Parth Kothari 2026
Made with ♥️ . © Parth Kothari 2026