TESSELL
Team
2 Product owners
1 Product manager
3 Developers
Role
Design Research
Conceptualisation
Design
Testing
Major Clients
Equinor
AON
Levi’s
Citizen Bank
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. It abstracts the complexity of managing database infrastructure, giving teams a single platform to handle everything from provisioning to compliance, at scale.
Tessell's customers run their infrastructure on managed database services and servers, and like any system, those servers need regular maintenance: OS patches, DB patches, storage resizing. Maintenance isn't a one-time task, it's a recurring need, and getting the timing wrong means real downtime for real businesses. This used to be a fully manual, support-team-run process. We built it from scratch into a self-service Maintenance Center, 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
Compliance Requirement
Regular OS patching is essential to meet customer needs, but currently
it is infrequent as it is done manually
02
Dependence on Support Teams
We depend heavily on support teams to handle customer patching requests,
causing delays and dissatisfaction.
03
Manual and inconsistent Patching
OS patching for managed database services is mostly manual, inconsistent,
and lacks automation
04
Limited Visibility
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,
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.
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.
The constraints that shaped the design
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.
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.
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.
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.
Set it once, forget it.
During service provisioning, users can schedule a maintenance window and enable auto-dispatch right away. If they do, Maintenance Center becomes purely a place to view or adjust that schedule later, not a mandatory extra step.
Adjust on the fly
Edit or update any existing maintenance window, cadence, time, recurrence.
Find what's unscheduled
View every resource without a maintenance schedule, and apply one directly from that view.
Stay ahead of updates
See available updates pending on any server, and schedule them without leaving the flow.
Introducing Fleets, without breaking the existing model.
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."
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.
Other Projects
NetBramha . 1to1help
B2C
Redesigning a mental wellness app so every user's journey feels personal
Personalised the 1to1help experience through mood tracking, tailored resource discovery, and a simplified session booking flow — reducing drop-offs at the step where users needed the most support.
Coming Soon
Complex systems
Permissions
B2B SaaS
Redesigning access management to give teams real control over who can do what
Overhauled Tessell's IAM from a broad, all-or-nothing permission model to a granular, rules-based system — letting customers set permissions in bulk, define exceptions, and tailor access across the entire platform.
Coming Soon
NetBramha . JioMart
Design for AI
B2C
Laying the foundation for AI-driven shopping at JioMart
Worked as a consultant embedded with JioMart's design and product teams — improving core app and web experiences while conceptualising AI-driven features to make shopping more intelligent and personalised at scale.
Let's Connect!
Portfolio is just a glimpse - let’s connect for the full story
+91 7768807788
Made with ♥️ . © Parth Kothari 2026