CloudGlance - Document Intelligence Platform

I shaped the structural foundation that would drive the entire platform:

• Project Management as the core workspace model
• File Manager with clear global and project-level scopes
• Tasks and Task Runs as repeatable workflows
• Indexing logic that makes the AI’s awareness visible
• AI Assistant with global and project-focused contexts
• Navigation hierarchy that preserves orientation
• Output flows and a split-view system for verification
• Tender Search as the entry point for discovering and evaluating opportunities
• Document Intelligence View for deep extraction, translation and document-level interaction
• Unified Search for cross-platform discovery across files, projects, chats and task outputs
• Settings and Task Defaults for workspace configuration and repeatable task inputs
• Real-time feedback for indexing status, task progress and streaming responses

Concepts like Project Management, the File Manager, Tasks, the AI Assistant, Tender Search, Document Intelligence and real-time processing were already part of the company’s direction or needs. My role was to define how these ideas would take shape as a product: clarifying their structure, connecting their relationships, and designing the architecture that holds them together.

Others I introduced as the platform took shape: the navigation system, output and split-view flows, Unified Search, and Settings with Task Defaults, filling gaps that only became visible once the product started forming.

While designing early screens, it became clear that CloudGlance needed a cohesive identity, something stable, mature and enterprise-friendly.

This wasn't part of the original brief; I initiated it because the platform needed a visual language that could carry the weight of document-heavy, high-stakes workflows.

Only after presenting the reasoning did the team align on the need for a new identity.

The earlier logo leaned literal and playful, revolving around a bulky "cloud" visual and green palette. It didn't reflect the seriousness of the workflow nor the enterprise clients they were approaching. The green colour palette also overlapped with the existing competitor landscape, making it harder to establish a distinct, enterprise-grade presence.

I suggested creating a new identity system that could:

• communicate maturity and trust
• visually hold the weight of enterprise workflows
• feel timeless, not startup-like
• live consistently across platform, website and future materials

The team welcomed the direction.

I designed a compact symbol built from C + G + a focal point, representing "glance", clarity and attention without being literal.

It reads cleanly at small sizes, aligns with enterprise expectations, and supports a more composed visual language.

I replaced the green palette with a composed, trustworthy blue, carrying the qualities the platform needed: stability, calm, reliability and professional maturity. Accents are used sparingly to maintain a quiet environment for long work sessions.

Typography follows the same restraint. A neutral, readable sans-serif with a structured hierarchy and comfortable line spacing, nothing decorative, entirely built for clarity and long-form reading.

Calm over clever
No flashy AI theatrics. The interface stays quiet, composed, and focused on the work.

Predictable patterns
Core interaction models repeat across the platform: tabs, headers, panels, and workflows behave consistently, helping users build familiarity as they move between features.

Depth only when needed
Users start with a clear overview and move into deeper layers only when they choose to.

Designed for experienced professionals
Clear labels, comfortable spacing, and no hidden interactions.

Transparency over abstraction
Users can always see what the AI referenced, which files were used, and where answers came from.

Intentional empty states
Guiding, informative, and restrained.

UI gets out of the way
Documents and outputs remain the primary focus.

Built for long work sessions
Soft neutrals, stable spacing, and low visual fatigue.

Consistent across contexts
The same feature behaves the same way regardless of where it is accessed. Files, the AI Assistant and search work identically whether used globally or within a project. Users never have to relearn interactions depending on context.

Navigation that always shows where you are

The sidebar highlights the active section and supports open, collapsed and overlay modes depending on the view. Logo doubles as a toggle to reduce header clutter. Main pages use static titles with no back action. Internal pages like a specific project, chat or task surface dynamic titles with a clear way back. The File Manager handles its own breadcrumb navigation within the content area for deep folder structures.

No matter how deep a user goes, they always know where they are and how to get back.

CloudGlance was designed around a unified way of framing pages, handling actions and running workflows, so the experience remains consistent as users move across different areas of the platform. From the beginning, it followed a shared structural logic that defines where context lives, where actions appear, and how work is carried out, instead of letting each screen define its own rules and layout.

Every page follows the same foundational logic:

• a clear sense of where you are
• a predictable place for actions and filters
• a focused work area
• supporting panels that appear only when needed
• consistent behaviour around navigation, spacing, and content flow

Actions across the platform follow the same structure. Starting a task, creating or editing a project, searching, or adjusting settings all use a shared interaction model, so actions feel familiar regardless of where they are triggered, and context is always preserved.

Workflows, the AI-powered tasks that drive the platform's real work, follow the same thinking. Every task fits into the same structural shell and the same execution flow, so users never have to learn a new interface for new intelligence.

By designing pages, actions and workflows around the same structural thinking, the platform avoids fragmentation as features grow. New capabilities can be added without introducing new patterns, allowing the platform to scale while remaining calm, learnable, and dependable.

Designed to give users orientation, and a quick path into action.

The dashboard acts as a stable entry point into the platform. Users land here, understand what's active, and move into their work without being distracted by unnecessary noise.

A small set of high-level indicators surfaces what matters across projects, files and tasks. Alongside these, users see recent items and a full activity log, providing traceability without overwhelming the interface.

From the dashboard, users can also act immediately: starting an AI-assisted conversation directly from the chat input, creating a new project, or running a task without navigating anywhere else. The shortcuts exist so common actions stay one step away, while the rest of the layout stays calm and focused.

The dashboard is not meant for deep decision-making. It exists to orient, ground, and guide users toward their next action.

A structured entry point for discovering and assessing opportunities before a project begins.

Tender Search is how work enters the platform. For teams whose day-to-day revolves around public tenders, this is the surface where opportunities are first encountered, browsed, filtered and assessed.

The surface was designed around a specific movement: from a long list of tenders to a confident decision. Filtering, sorting and saved views exist to support that movement, not to overwhelm it. Each tender card surfaces a relevance signal drawn from the platform's AI analysis, so the most aligned opportunities surface first by default, letting experienced professionals scan quickly and decide where to look deeper, without wading through thousands of listings.

The tender detail view is where assessment happens. The information that usually lives across multiple sources, metadata, financials, key dates, linked documents, sits inside a single readable layout, paired with AI-generated insights. The AI analysis offers a relevance score, eligibility view, strengths and weaknesses, and a go or no-go assessment, all grounded in the organisation's own context and criteria. This gives experienced professionals a starting point for their own judgement rather than replacing it.

When a tender looks worth pursuing, users can add it as a new project in a single action. The documents come with it, automatically indexed and carried into the project. The connection between Tender Search and Projects is designed to be a continuation, not a handoff.

Tender Search sits alongside the rest of the platform, not above it. It is the beginning of a workflow, not a separate product.

Where teams organise, manage, and act on work within a consistent structure.

Projects are the core workspace in the platform. They act as stable containers that hold documents, automations, outputs and activity, while adapting to the specific purpose of the work.

CloudGlance currently supports three project types: Bidder, Issuer and RFX. Each represents a different kind of workflow, but the overall project structure remains the same. What changes are the available automations and actions within a project, not the way the project is navigated or understood.

This allows the platform to support varied client needs:

• some organisations only bid
• some only evaluate
• some manage requests for quotes, proposals or information
• others do a combination of these

all within a familiar, predictable project framework.

Creating a project is a lightweight action. Users can start with a blank project, or link a known tender directly from the creation flow by searching for its tender ID or name. This keeps the discovery-to-project bridge open even when users already know what they want, without forcing them back through Tender Search.

The projects listing stays clean: a scannable view of active work with light filtering to find what matters. Projects can also be pinned, keeping important ones within reach directly from the sidebar.

By keeping the project structure consistent and allowing capabilities to vary inside, it reduces cognitive load while remaining flexible as the platform evolves. New project types and automations can be introduced over time without breaking the core experience or requiring users to relearn the platform.

The entry point into a project, shaped by its type and context.

Opening a project always lands the user here. The overview establishes context, surfaces the project's key details in an editable form, and offers a direct path into the available tasks. Depending on the project type, it adapts to present what is most relevant for the work ahead.

Every project, regardless of type, shares the same core layout: project details, editable financials and dates tables, and task cards showing the automations available for that project type. The structure stays predictable and learnable no matter what kind of work the project represents.

Where the overview becomes interesting is in how it adapts to the project's context:

• When a Bidder project is linked to a tender, the overview adds a dedicated tender overview table showing the linked tender's key details, and auto-fills financials and dates directly from the tender data. The connection between discovery and project work stays visible.
• When a Bidder project is created without a linked tender, users can run AI analysis on the project documents. It auto-fills financials and dates from the files themselves, and surfaces an analysis section grounded in the same org context used throughout the platform.
• Issuer projects always work from their own documents. Running AI analysis auto-fills the same financial and date tables, surfaces a context-specific analysis, and generates an editable evaluation rubric that feeds directly into tasks. The AI does not just extract data, it prepares structure for the work ahead.
• RFX projects keep the same overview layout but do not currently use AI analysis.

Users can review, adjust or override anything. The AI reduces repetitive setup without taking control away from the people who need to verify the details.

Rather than acting as a reporting dashboard, the overview is designed to help users settle into the project: providing clarity, direction, and a clear sense of what can be done next.

All documents live within a single system, accessed through different contexts.

The platform uses a unified file system that supports both organisation-wide document management and project-specific work without fragmenting where files live or how they are handled.

Users can access the full file manager directly from the platform to browse, organise, and manage documents across the organisation. Within a project, the same system is presented in a focused way, showing only the files relevant to that project and keeping users anchored to their current context.

The file system is structured around three primary areas:

• Resources, used for shared organisational files
• Templates, used for standardised files required by specific tasks
• Projects, where each project has its own dedicated folder that acts as the root for all project-specific documents

This structure ensures clarity and control. When working inside a project, users remain within that project's scope and cannot accidentally move out of context, reinforcing trust and predictability in document-heavy workflows.

Any uploaded file can be opened in a viewer that adapts to its format. PDFs, spreadsheets, Word documents, Markdown and HTML all open within the same viewing experience, so review sessions stay uninterrupted regardless of what kind of document is at hand.

Uploading is only the first step. The platform indexes documents to make them AI-aware, and a dedicated processing view keeps that work visible. Users can see which files are being indexed, which are ready, and which need attention, so the AI's awareness of their content is never hidden behind a silent loading state.

Once indexing completes, each file gains an AI-generated summary, giving users a quick sense of what the document is about before they commit to reading it.

Beyond the AI's awareness, users can also contribute their own. Any indexed file supports user annotations: notes or comments on specific parts of the document. These annotations do not just live for the user, they are picked up by the AI when the file is referenced later, turning human insight into another grounding signal for future tasks and conversations.

AI-powered workflows designed for repeatable, document-heavy work.

Tasks represent how CloudGlance applies its document intelligence within a project. Rather than exposing AI as an abstract capability, the platform packages intelligence into structured workflows that teams can run with confidence.

Tasks are project-bound by design. Users only see the workflows relevant to their project type, nothing more.

Each execution of a task is recorded as a Task Run, preserving a clear history of what was processed, when it was run, and what outputs were generated. Every project's Tasks tab presents this history as a structured list, with each run carrying its own context, status, and pathway back into the output.

Many tasks require supporting files to run properly: organisational letterheads, stamps, signatures, or reference sheets like go/no-go criteria. To avoid the friction of selecting these every time, the platform lets users configure defaults per task type in Settings.

By fitting AI tasks into the platform's shared structure, new intelligence capabilities can be introduced without changing how users interact with them.

The current task library is organised by project type. Bidder projects can run Smart Form Extraction & Filling, Tender Risk Analysis, and Document Intelligence Review. Issuer projects can run L1 Bidder Evaluation and Bidders Package Compliance Analysis. RFX projects can run RFQ Product Matching & Deviation Analysis. Each task is described separately in the platform; together, they cover the workflows the platform is currently built to support.

A predictable way to initiate AI-powered work without breaking context.

Starting a task follows a consistent, modal-based workflow designed to keep users focused on their current context. Instead of navigating away to separate screens, task initiation happens within a contained flow that guides users through a clear, repeatable sequence: selecting the task type, reviewing inputs, and confirming execution.

The workflow adapts to where the action is initiated:

• when starting from a project, the context is already set
• when starting from higher-level surfaces, the necessary context is requested upfront

Inputs are often already prepared. Configured task defaults, along with project-linked documents, flow into the modal automatically, so users mostly review and confirm rather than gather files from scratch.

By keeping task initiation consistent across the platform, the structure ensures that starting AI workflows feels familiar regardless of where users begin, reinforcing confidence, reducing friction, and supporting scale as new tasks are introduced.

The space where a task lives, from the moment it is submitted until it becomes a reviewable output.

Once a task is initiated, the platform creates a dedicated Task Run page. This page is the task's home from start to finish, holding its context while it runs and becoming its output once complete.

Before results are ready, the Task Run page communicates state rather than leaving users guessing. Whether the task is running, has failed, or was cancelled, the current state stays visible at a glance, so users always know where their work stands. During these states, the left pane surfaces the Details of the run: what was triggered, when it was started, which files are involved, and how the task is structured.

Once the run completes, the same page transitions into the actual output view. A new Content tab in the left pane leads with navigation across the output sections, while Details remains one toggle away. The structure stays the same, but its purpose shifts from watching to reviewing.

The primary output occupies the main work area, presented in a format shaped by the task itself. Users always read results in a layout that matches the shape of the intelligence rather than a generic container.

Verification is never a separate step. Every result in a task output carries source references that can be traced back to the exact place in the original document. Users do not have to take the AI's word for anything. The evidence is always reachable.

When outputs need to leave the platform, they can. Task results can be exported as PDF reports, and structured results like extracted forms can be downloaded as ZIP archives, ready for internal review, submissions or record-keeping.

By connecting submission, processing, results and sources into a single continuous space, the platform supports both quick understanding and deeper verification. This keeps AI outputs transparent, navigable, and dependable, especially in workflows where accuracy and accountability matter.

A conversational layer that adapts to user intent across the platform.

The AI Assistant in CloudGlance acts as a flexible, conversational layer that users can access from anywhere in the platform. Rather than being tied to a single screen or workflow, it responds based on what the user brings to the conversation.

The assistant has access to everything in the workspace: projects, files (with any user-added annotations), task runs, and the organisation's provided info and files. A simple question requires no setup. It already knows what the user has, and draws from it to help.

Users can start a conversation from the dashboard or create a new chat from the sidebar. When they want to be more specific, they can guide the assistant's focus:

• attaching external files for ad-hoc queries
• focusing the conversation on a specific project
• enabling web search when broader information is needed

These are not requirements. They are guides. The assistant uses them as references while working, narrowing or extending its reach based on what the user signals.

When answers reference the workspace, they arrive grounded. Every claim the assistant makes carries a trace back to its source, so users can verify anything the AI says without leaving the conversation. Answers also stream in as the assistant thinks, keeping the conversation responsive.

Recent chats are always visible in the sidebar for quick return. For deeper navigation through history, an All Chats view opens a searchable modal, and any chat that matters can be pinned to keep it within reach.

This approach allows the assistant to remain lightweight and supportive, useful for exploration, clarification and quick checks, while more structured or repeatable work continues to live inside tasks.

By keeping the assistant context-aware and guidable when needed, the experience ensures that conversational AI feels integrated into the platform, not separate from it.

Every AI-generated answer can be traced back to the exact place it came from.

Trust in an AI platform is not built through confidence in the answers. It is built through the ability to verify them. CloudGlance treats this as a structural decision rather than a feature, making source references a first-class part of the experience.

When a document is indexed, the platform does more than make it searchable. It identifies the structural elements on every page, Titles, Body content, Tables, Images and more, and records their exact positions. These detected elements become the foundation of an annotation layer that sits on top of the document whenever it is viewed.

The inline citation markers and source references visible in task outputs and chat responses hint at something deeper. They are not just labels. Clicking any citation opens the source document in the right pane, scrolled to the correct page and highlighting the exact element the answer came from. Users stay exactly where they are, the evidence just appears alongside.

The result is an experience where the AI never feels like a black box. Users do not have to take its word for anything. They can always see the underlying evidence, review the original context, and decide for themselves whether the answer holds up.

Verification was not treated as a feature added on top. It was treated as the structural decision that determines whether the rest of the platform can be trusted with the kind of work CloudGlance is built for.

A single surface to find anything, anywhere in the platform.

As the platform grew to hold more projects, more files, more conversations and more task runs, the question of "where is that thing I was working on yesterday" became real. Unified Search is the answer.

Accessible from anywhere through a keyboard shortcut, Unified Search opens a single modal that searches across the entire workspace: projects, files, chats and task runs, all at once. Users do not need to remember where something lived or which section to look in. They type what they remember, and the results surface in context.

Most result types (projects, chats, task runs) return based on direct keyword matches. Files go further. Because they are indexed and carry AI-generated summaries, file search runs in two phases: a quick pass returns the closest literal matches instantly, followed by a semantic pass that uses the file's summary and content to catch meaning-based results. Users can describe a file in natural language, even when they cannot remember its name, and still find what they are looking for.

Results are grouped by type, with each kind of result presented in a card layout suited to what it represents. A project result looks different from a file result, which looks different from a chat result, because the information users need to recognise them is different.

Unified Search is designed to stay out of the way when not needed, and to be instantly reachable when it is. It is another expression of the same principle that runs through the platform: users should always know where they are, and should always be able to get where they need to go.

A calm configuration layer, organised around who is changing what.

Settings opens as a focused modal with a sidebar of tabs, following the same UnifiedModal pattern used everywhere else in the platform. Users do not navigate away to manage their account or workspace, the configuration layer simply slides over the existing surface, keeping context intact.

The settings are divided into two clear groups, reflecting the two kinds of decisions a user actually makes.

Personal settings are the ones any user can manage for themselves. The Account tab is where users see and update the basics tied to their identity in the platform. Preferences holds everyday choices that shape how the interface looks and feels, including theme, layout and viewing density. Security manages password updates and the safety of the active session. Data Privacy gives users control over their own search history and locally stored data, so they decide what stays and what gets cleared.

Workspace tabs sit at the organisational level, where admins shape how the workspace itself behaves. Workspace General holds the broader workspace setup, including auto-indexing behaviour for uploaded files (where available) and the customisation of project statuses. Features lists the main and additional capabilities available to the workspace, giving users visibility into what their organisation can use, with room to grow into usage limits and similar information as the platform evolves.

Two workspace tabs deserve a closer look, because they exist as design responses to specific friction in the platform.

A transparent record of who did what, and when.

Within each project, People & Activity surfaces both the people involved and the work they have done. It brings together roles, actions and system events into a single, readable timeline.

Activity logs capture key moments: task runs, file changes, updates and interactions, helping teams understand how a project has evolved and making it easier to trace decisions back to their source. The same kind of activity feed exists at the workspace level on the dashboard, where it covers everything users do across the entire workspace. This way, users can zoom in on a single project or step back to see the broader rhythm of work, without learning a different model in each place.

By keeping this information accessible and structured, CloudGlance supports accountability and confidence in collaborative, document-heavy workflows where clarity and traceability matter.

A first encounter that introduces the platform before the user even logs in.

Sign In is more than a credentials page. It is the first moment a new user meets CloudGlance, and the design treats it that way. Rather than dropping users into a bare form, the page introduces the platform through three working glimpses of what it actually does.

These three animations, designed and built for the brand's broader presence and reused here, were chosen deliberately. They represent the three pillars users need to understand the platform at a glance: the AI Assistant grounded in real project context, the live indexing flow that turns raw documents into AI-aware material, and an Automations preview built around Form Extraction. Together, they give a new user a simple mental model before they even sign in: ask the AI, understand your files, run intelligent tasks.

The other side of the screen holds the actual sign-in form, branded and quiet, surrounded by softly drifting document panels and a gentle gradient mesh in the background. The tagline below grounds it all: AI Analysis. Document Extraction. Structured Insights.

The Sign In page carries the same visual language used across the platform, the website and the brand's other materials, but here it shows more of its expressive side. The platform itself stays minimal because it is a working environment for long sessions, while the sign-in screen has room to breathe and welcome.

The result is a sign-in page that doubles as the platform's most concise introduction. The design intent was clear: the moment a new user lands here should already communicate what kind of platform sits behind it, before they sign in.

One structural backbone, inherited by every page.

Unified Layout is the structural backbone for every page in the platform. A single, composable page structure that every screen inherits from.

Instead of treating pages as independent layouts, the platform is built from a fixed set of structural regions, each with a strict responsibility. Pages do not decide layout. They declare intent and assemble themselves using predefined parts.

One structural model, inherited by every action.

Unified Modal is the structural model behind every action in the platform. Just like Unified Layout shapes pages, Unified Modal shapes actions, a single, composable structure that every action-based interaction inherits from.

Instead of treating modals as one-off UI flows, every action is built from the same internal structure. The modal handles layout, behaviour, and state. Individual actions only provide content and intent.

One configurable system, holding every AI workflow in the same shell.

Unified Task is the structural model behind every AI workflow in the platform.

The design problem came first. Tasks were going to keep growing as the platform added new capabilities, new domains and new automations. If every task was designed and built as its own page, two things would go wrong fast. The work of producing each new task would scale with the platform, and worse, every new task would feel like its own island, behaving slightly differently from the ones around it. The platform would fragment from the inside.

Unified Task was the answer to that. A single system that holds every task in the same structural shell, so the user always encounters tasks the same way, no matter what kind of intelligence the task represents.

In design, this meant defining one canonical structure for tasks: how they start, how they communicate state, how they present their results. In code, it meant turning that structure into a system where adding a new task no longer required designing a new page. Each task became a single configuration file that declares the task's intent and content. The system reads the config and builds the rest.

The system itself is built around three structural parts.

What three composable systems changed about how work happens on the platform.

Once these three systems were in place and enforced in the frontend codebase, the way work happened on the platform changed fundamentally.

Page creation shifted from designing layouts to assembling intent. New screens no longer defined their own structure. Instead, they composed themselves from existing regions, following the same rules every other page used. Layout-level decision-making disappeared from individual features, and consistency became the default rather than something to maintain.

Actions followed the same shift. New actions no longer needed new flows. Create, edit, search, settings and task initiation all started from the same structural model, behaving consistently regardless of where they were triggered. Users encountered the same mental model across every action type, and modal behaviour could be updated once and applied everywhere.

Tasks moved even further. Adding a new AI workflow once required creating five to eight files across input forms, state handling, output rendering and routing. Now it requires writing one config file. The system does the rest, plugging the new task into the same execution shell every other task already used.

The cumulative effect was bigger than any single pillar. Pages became composable. Actions became composable. Workflows became composable. The platform stopped behaving like a collection of screens and started operating as a system of composable surfaces, where new capability could be added without rethinking the foundation underneath it.

Beyond what it enabled, this also changed what it took to maintain. A change to layout behaviour, action patterns or task structure no longer meant touching every screen. One change in the right place flowed everywhere it needed to. The platform could keep growing without the work of maintaining it growing alongside.

The moment the platform turned out to be two layers, not one.

Somewhere along the way, the work of building CloudGlance produced something larger than CloudGlance.

The pillars I had been designing and enforcing in the codebase were not, on closer inspection, all the same kind of thing. Two of them were product-agnostic. They described how to compose pages and how to handle actions, regardless of what the product actually was. The third was different. It described how AI tasks ran inside this specific product. CloudGlance.

I had not been building one platform. I had been building two layers that happened to share a codebase.

The base layer is the foundation. It contains everything that holds the system together regardless of what the system is being used for. Unified Layout sits here. Unified Modal sits here. So does the visual system that shapes every surface, the shared component vocabulary, the theming that supports light and dark modes, and the global navigation and interaction patterns that define how any product built on this foundation should behave. None of these are specific to document intelligence, tenders or CloudGlance. They are simply how a product on top of this architecture works.

The platform layer is everything that makes CloudGlance the product it is. Project Management, the File Manager, Tender Search, the AI Assistant, Citations and Verification, Settings, and Unified Task. These are the features that turn the base layer into a document intelligence platform. They use the base layer to render themselves, and they live entirely on top of it.

This separation was the natural result of how I had approached the work from the beginning, building each piece of the system to do one thing cleanly, without bleeding responsibilities across layers. What was unexpected was how much the base layer could carry on its own. It turned out to be robust enough to support a completely different product, with completely different features, without changing a single thing underneath.

The same systems, adapted when space runs out.

Mobile access did not come from a separate design effort. It came from recognising that the same systems that held the desktop platform together could absorb mobile without a parallel design.

The decision itself was practical. The team wanted mobile coverage but was leaning toward a native app, with all the cost, separate codebases and maintenance that comes with it. A native app belonged in the future, not the present. What was actually needed right then was the ability to open the platform on a smaller screen and continue working without re-learning anything. The platform was already a web app. It just needed to behave like one when accessed from a phone.

The base layer made this possible. Because Unified Layout, Unified Modal and Unified Task were all built around composable structural regions, mobile became a matter of teaching those regions how to behave when space ran out, not redesigning them from scratch. The sidebar collapses into an overlay. Side panes become full-screen sheets that slide in from their original directions. Modals adapt into swipeable bottom sheets. Tasks follow the same shifts because they sit on top of the same systems.

Mobile was given the same care the rest of the platform was. Favicons, a web app manifest, an app name and theme colours were set up so that when users add the platform to their home screen on iOS or Android, it behaves like a native installation. The CloudGlance identity carries over completely. The user is not opening a website. They are opening CloudGlance.

Mobile is honest about its limits. Task outputs are text-heavy and citation-rich, and that kind of long-form review experience is genuinely better on a larger screen. What mobile covers instead is everything around the deep review: discovery, initiation, monitoring, light interaction. The decision was to make mobile useful for the in-between moments of a workflow, while leaving the heavy lifting to the desktop session where it actually fits.

Mobile became an extension of the system, not a parallel design. The base layer carried it.

When the base layer left CloudGlance and held up another product entirely.

Some of the strongest signals about a system are the ones you do not plan for.

CloudGlance, like most growing companies, eventually needed an internal management platform. A place for the team to handle organisations, users, defaults, overrides, configurations, internal product data and the dozens of small operational decisions that make a customer-facing product runnable in real life. Studio is that platform.

Studio was originally built by the team for the team. It was working, but it had grown organically, with its own rough base layer assembled along the way. As more areas were added, the same problems that had plagued CloudGlance before the systemisation work began to appear: drift, inconsistency, decisions multiplying every time a new section was needed.

The team asked me to make it better.

What I did was straightforward in description and revealing in practice. I removed the existing base layer entirely and replaced it with mine. The same Unified Layout. The same Unified Modal. The same visual system, the same component vocabulary, the same theming, the same global navigation and interaction patterns I had built for CloudGlance. None of it was redesigned for Studio. None of it needed to be.

Once the base layer was in place, Studio's pages began to fall into the structure naturally. Organisations, Platform Catalog, Configurations, Cost Management, internal product modules. Each one composed itself out of the same regions every CloudGlance page used. The work that remained was Studio's own platform layer: its specific features, its specific flows, its specific decisions. With the structural questions already answered, that work was significantly faster and more focused.

Studio is built on a different framework underneath. CloudGlance runs on Next.js, Studio runs on React with Vite. The base layer carried across that difference too, because it was never tied to a specific runtime. It was tied to a set of structural ideas that any modern frontend can implement.

This was the moment the base layer stopped being a theory.

Studio even carries its own variant of the brand mark, identified as CG Studio. The same identity, the same restraint, the same calm visual presence, just signed differently.

Two products. Different domains. Different runtimes. One foundation. The same Unified Layout, the same Unified Modal, the same visual language, the same interaction patterns, holding up two completely different platforms with no reduction in quality on either side. The base layer was real, and it was strong enough to do its job in a place I had not designed it for.

What I had built for one product turned out to be infrastructure for more than one. That changed how I think about the work.