Appsatile SaaS Platform

Appsatile brings separate business tools into one workspace.

Growing teams often run their work across many disconnected tools: one for chat, another for tasks, others for finance, property records and documents. Each tool has its own navigation and logic, and people end up copying data between them.

Appsatile replaces that patchwork with one connected environment. Every app (tasks, finance, property, documents, chat) shares the same structure, the same interaction patterns and the same data.

The design work covered the product structure, the core workspace experience (navigation, multitasking, views, search, density and the context sidebar) and the design system and brand every app is built on.

The work was done in close collaboration with the founder, who acted as product owner and, as an experienced user of business tools himself, as an expert user. Research drew on people already using an early MVP. That MVP was not developed further: it proved the idea, and the team decided to build a new product on what its users had shown.

The hard part was not any single screen, but keeping one product coherent as it grew.

The platform had to host many apps, each used by different roles. A property manager, an accountant and a team lead may open the same record, but each needs a different level of detail, different actions and a different path through it.

The structure had to stay consistent across apps, yet adapt to the task in front of the user:

• Navigation had to stay predictable, even in deep hierarchies.
• Tools had to appear in context instead of crowding every screen.
• Users had to switch between open items, views, filters and search results without losing their place.
• New apps had to plug in without redesigning the shell each time.

How do you make a complex business platform feel like one product: easy to learn, flexible for each role, and structured enough to grow?

Before the screens, the product needed a model that every app could follow.

The workspace is built around four persistent areas, each with a clear role.

Navbar

Compact and extended. Side navigation with access to apps, hubs, records, folders, files and deeper structure.

Topbar

Global search, profile and the tab manager.

Content area

The main working area: a context bar on top (view switcher, filters, local search, actions) and the work area below, which shows the data in the view that fits the task.

Pilot sidebar

Contextual details, actions, communication and related records.

This structure stays consistent across the platform, so users can move from finance to recruitment, documents, tasks or operations without relearning the interface.

Navigation

Navigation works on two levels: moving between apps, and moving inside app content.

The compact navbar keeps the main areas always available. When needed, it expands to reveal deeper structures such as folders, files, task lists, records and nested sections.

Breadcrumbs help users understand where they are. Pinned and current levels keep frequent locations close, so users can move through complex structures without losing orientation.

The main navbar also switches between app-centric and hub-centric modes, so the same navigation serves people who think in tools and people who think in places.

Decision: pinned and current levels sit at the top of the extended navbar. User feedback showed that people moved between the same few places all day, and the design logic supported it: with so much work happening deep in folder structures, keeping frequent places one click away proved very useful.

Topbar

The top bar keeps global tools available from anywhere in the product.

Tab manager

Open work streams as tabs.

Global search

Search across the whole workspace.

Profile and settings

Account and preferences.

Widgets

Users pin the ones they need: metrics, clock, chats.

Tab manager

Users often work across several apps at once. Each open window appears as a tab in the topbar, so users can organise them and switch between them in one click. Each tab keeps its state: what was open, the filters applied, the scroll position. Switching doesn't reload the page or send the user back through folders. The tab area collapses to save space and expands when the user needs quick access to everything open.

• Tabs hold files and views. A single record opens in the Pilot, not as a new tab, so the tab bar stays manageable.
• Pinned and grouped tabs stay in the workspace across sessions; other tabs reset with each new session.
• Each app opens in a single tab by default; a new tab opens only when the user chooses.

Content area

The content area shows the same records in the view that fits the task: three views over one dataset.

List

Quick scanning and bulk actions.

Table

Structured comparison across attributes, like a database.

Board

Stage-based workflows, with drag and drop.

Switching view keeps the shared context. Filtering, sorting and the actions for the current task stay next to the data instead of buried in menus.

User interviews drove one decision in particular: people didn't just want to filter, they wanted to keep their full setup – columns, order, sorting – and return to it. So a configuration persists instead of resetting.

Pilot sidebar

The Pilot is the right-side context layer for the selected record. Opening a record there instead of in a new tab keeps the tab bar for files and views, and gives every record one consistent place.

It holds the record's details, custom fields, comments, linked records and related actions. It is also the single place for an object's settings, properties and permissions, so admin controls never crowd the main workspace.

Decision: a record opens in the Pilot, not in a new tab. The list or board stays in view, so users keep the context: they see where the record sits while they work with its details. A side panel for record details is an established pattern in the tools people already use, so keeping it meant there was no new habit to learn.

Search was built into the workspace at different levels, so users can find information from the place where they are already working.

In navigation panels

Quickly locate tasks, lists, files, folders, messages and other workspace items.

Inside the working area

Local search, filtering and sorting for focused work with visible records in a list, table or board.

Global search

Across the user's apps and connected data. Results can be narrowed by app, object type or context, and a preview lets users inspect an item before opening it.

This keeps search close to the current task and reduces the need to move through modules manually.

The platform needed to support both high-volume processing and careful review.

Some users work faster with compact records, dense tables and shorter scanning paths. Others need more space for reading, comparison and decision-making.

Choose interface density

CompactDefaultComfortableSpacious

Share your projectCopy link

Add people

AAJAlice JohnsonDDPDiana PrinceEmma WilsonOlivia TaylorRuth KimAALLaura HarrisAAMAndrew MartinJacob JacksonBBDBetty DiazRRWRaymond WilliamsJJRJennifer RodriquezStephanie BrownJJDJerry DavisAALAnna Martinez

Can viewCan edit

AAJAlice JohnsonDDPDiana PrinceEmma WilsonOlivia TaylorRuth KimAALLaura HarrisAAMAndrew MartinJacob JacksonBBDBetty DiazRRWRaymond WilliamsJJRJennifer RodriquezStephanie BrownJJDJerry DavisAALAnna MartinezBob SmithCharlie BrownEEHEthan HuntFiona GallagherGeorge WashingtonHHBHannah BakerIsaac NewtonJJRJulia RobertsKKHKevin HartLLNLiam Neeson

Invite

You can add multiple people as collaborators

Notify when tasks are added to the project

Access settingsMy workspace

Default density selected.

Token-driven density

Four density levels let each user decide how much the workspace shows at once. Compact suits people processing records all day, such as accountants. Spacious suits people reviewing and deciding, such as managers.

One mode variable, Component Size (SM, MD, LG, XL), drives spacing, typography, icon size and component proportions together, with Medium as the default. Hit areas are protected separately from visual size, so even the most compact mode keeps every control easy to click.

To make many apps feel like one product, consistency had to live in the system, not in discipline.

The system holds 1,100+ tokens in three tiers (primitive, semantic and component-level) across 15 variable collections. They cover colour, typography, spacing, radius, elevation and density. One change propagates everywhere, and light and dark themes come from the same source.

LightDark

Colour shows how it works. 248 semantic tokens in six groups (text, background, action, status, border, depth) sit between components and raw values, named by category, role and state, such as action/primary/hover. Components never use a raw colour, and Brand is a single primitive alias: change it once and the whole product follows.

On top of the tokens sit 70+ components, built atom first: buttons and inputs, then patterns such as lists, modals and search, then the workspace itself: navigation shells and data views.

Icons that follow the text. In a fixed-stroke system, a thin icon disappears next to bold display type and dominates small helper text. Here, icon size and stroke weight are derived from the text style: choose a text style and the matching icon specification comes with it. The library holds 868 icons covering 20+ work domains.

Documentation and handover. Each component page held its behaviour notes, token links and prototypes, and served as the source of truth for developers alongside Storybook. Once a component shipped, its documentation moved to a separate file to keep the library fast.

Full breakdown on Behance

Behind the main structure sit dozens of smaller flows, each built from the same components and rules.

Date and time picker

One picker logic for dates, times and ranges, later reused for the calendar view.

Filters

Building, combining and saving filter sets inside any view.

Labels and colour picker

Creating and colouring labels without leaving the record.

Custom properties

Adding fields to a record type, with the right input for each data type.

Alerts and notifications

One pattern for system messages, from inline hints to blocking alerts.

Onboarding

First steps into the workspace for a new user.

Identity built into the product.

The logo and colour system were designed alongside the product and tied into the same token layer. Brand colours map to semantic action roles, so identity is part of how the UI is defined, not painted on top. A rebrand becomes a token change, not a manual sweep across every screen.

Logo

The logo is built around the letter A, referencing alpha as a symbol of beginnings and leadership. Its balanced lines and circular negative space create a clean, flexible mark, while the extended strokes add a sense of movement and openness.

Brand colour

The brand palette is carried through the interface at key interaction points: primary actions, selected states, focus indicators and product identity elements such as the favicon.

Brand blue#0077FF

The full MVP was not released. Business priorities, funding and a fast-moving AI market led to the project closing before launch.

What worked

• Testing early versions with real users, so decisions came from actual needs.
• A design system that made new modules quick to build, test and keep consistent.
• A small team with the freedom to experiment and change direction fast.

What was challenging

• Many modules in progress at once gave wide feedback, but made it harder to see the product as one whole.
• Each business type had its own needs, so choosing what to build first was a constant balance.
• The AI landscape changed quickly, and some ideas had to be rethought while still in testing.

My conclusion

An early product grows best from one core problem, solved well for one type of user and released as soon as it works. AI now speeds up research, design and build, but deciding what to focus on, and what the MVP really is, is still a product decision.

Thanks to the design and development team, and to the founder, for the space to experiment and learn.