01
Visits
Capture the visit. Keep the knowledge.
The first version focused on one core problem: creating a central record of client visits so important information didn't disappear into individual notes, conversations or spreadsheets.
Product Engineering · SaaS · Business Operations
THEOS Enterprise
I saw a gap. So I built the system the business didn't have.
A business operations platform built to bring client activity, product information, sales workflows and quotation processes into one connected system.
The Project
A system built around the way the business actually worked.
THEOS Enterprise grew from a simple problem: important business information was spread across Excel, email, WhatsApp, verbal communication and individual knowledge.
Client visits could be difficult to trace. Product information was not always easy to find. Sales activity lacked a central view. Quotation requests could move through several different communication channels before reaching the people who needed to act on them.
The goal wasn't to replace every existing system. It was to create a practical operational layer that connected the information and workflows the business needed every day.
The Problem
Important information was everywhere — and nowhere.
Client information, visit details, sales activity and product knowledge were spread across Excel, email, WhatsApp, verbal communication and individual knowledge.
A client visit could happen without there being a clear central record of what happened. Product information was not always easy to find. Sales activity lacked a single view. Quotation requests could move through several different communication channels before reaching the people who needed to act on them.
The issue wasn't simply that some processes were manual. It was that valuable business knowledge could become difficult to find, difficult to trace and ultimately easy to lose.
The real problem wasn't the lack of technology.
It was the lack of connected information.
Starting Small
The first version didn't try to solve everything.
The first goal was simple: give the business a central place to capture client visits and retain the information that came from them.
From there, the product could grow around the problems that became clearer through real use — rather than trying to predict every requirement upfront.
V1
Capture the visit. Keep the knowledge.
How THEOS Evolved
THEOS didn't start as a platform.
It became one.
The product grew as real requirements surfaced through use. Each stage solved a specific problem while creating the foundation for what came next.
02
Clients
Build the client record around the interaction.
Once visits were being captured, the next requirement was understanding who those interactions belonged to. Client information became part of the same connected workflow.
03
History & Activity
Make activity visible.
Visit history and activity tracking made it easier to understand what had happened, what was happening now, and where follow-up was needed.
04
Pipeline & Dashboards
Turn activity into operational visibility.
As more information accumulated, the product evolved beyond record keeping. Dashboards and pipeline views provided a clearer picture of activity and the state of the sales process.
05
Product Catalogue
Connect the products to the people selling them.
Product information became its own connected system, allowing machines, assemblies, components and parts to be organised into a structure that could be searched and understood during the sales process.
06
RFQ Workflow
Turn quotation requests into a workflow.
The quotation process became structured inside THEOS, allowing representatives to build requests from the catalogue instead of relying on fragmented messages, emails and verbal handovers.
07
Sage Traceability
Connect the operational workflow to the financial one.
THEOS doesn't replace Sage. Instead, the RFQ process hands off to the existing financial workflow, with the Sage quote number recorded back in THEOS to create a traceable connection between the two systems.
What started as a way to capture visits gradually became a connected operational platform.
Each new capability came from a real requirement that emerged along the way.
The Product
From capturing information to connecting the workflow.
As THEOS grew, each new capability was designed around a real operational need. The result was a system that connected the information people needed with the work they actually had to do.
01 · Operational Visibility
Make activity visible.
Once client visits and activity were being captured centrally, THEOS could turn that information into something the business could actually see and act on.
Activity tracking gave representatives a clearer record of their work while providing a more useful operational view of what was happening across the business.
Capture the work. Keep the history. Make the activity visible.
02 · Product Intelligence
Connect the products to the people selling them.
The product catalogue became more than a list of products. It needed to reflect the way engineering products were actually structured.
Machines, assemblies, components and parts could be organised into connected relationships, giving representatives a clearer way to find and understand the information they needed.
MachinesAssembliesComponentsParts
03 · Quote Workflow
Turn quotation requests into a connected workflow.
One of the biggest opportunities was the quotation process. Requests could previously move through WhatsApp, email, verbal communication and paper before reaching the people responsible for producing the quote.
THEOS introduced a structured RFQ workflow that allowed representatives to build requests from the product catalogue and submit them into a central process.
RFQ Overview
RFQ Detail
The Workflow
01 · Build
Representative selects products and creates the RFQ.
02 · Submit
The request enters the central THEOS workflow.
03 · Process
Accounts uses the request to create the quote in Sage.
04 · Reference
The Sage quote number is recorded back in THEOS.
05 · Trace
The operational request and financial quote remain connected.
The product wasn't built around features.
It was built around how the business needed to work.
Engineering Behind It
The product evolved.
So did the architecture.
THEOS started small, but the engineering underneath it had to evolve as the product grew. New workflows introduced new relationships, new requirements exposed gaps in the data model, and the system had to keep adapting without losing sight of the business problem.
I worked across the product from the interface through to the data and deployment layers, learning and refining the system as real requirements emerged.
01 · Architecture
A product architecture shaped by real requirements.
THEOS is built with Next.js, React and TypeScript on the application side, with Supabase and PostgreSQL providing the data and backend foundation.
The architecture wasn't designed around an abstract enterprise blueprint. It grew alongside the product. As visits became clients, clients became activity, activity became pipeline and the product catalogue and RFQ workflows were introduced, the underlying relationships had to evolve with them.
That meant revisiting structures, relationships and queries as the product changed rather than treating the original design as something that could never move.
Core Relationships
Clients
Business relationships and associated information.
Visits & Activity
Interactions and operational history connected to the client relationship.
RFQs & Items
Structured quotation requests and their selected catalogue items.
Product Catalogue
Machines, assemblies, components and parts represented as connected product information.
02 · Data Modelling
Model the relationships behind the workflow.
As the product expanded, the data model became increasingly important. Information couldn't simply exist as isolated records — the relationships between it were what made the workflows useful.
RFQs, for example, use a parent request with associated line items and history, allowing the quotation process to remain structured and traceable as it moves through its different states.
03 · Access & Security
The interface isn't the security boundary.
As THEOS moved from a simple internal tool towards a multi-user application, access control became an important part of the engineering work.
Authentication and role-based access determine what users can access through the application, while PostgreSQL row-level security provides an additional layer at the data boundary.
Access control needs to exist where the data lives — not only where the buttons are rendered.
Operational → Financial
THEOS RFQ
Operational request created by the representative.
↓
Accounts
Request is processed through the existing financial workflow.
↓
Sage Quote
The Sage quote reference is recorded back in THEOS.
04 · System Integration
Connect new workflows to existing systems.
THEOS wasn't intended to replace the company's existing financial system. Instead, it needed to work alongside it.
The RFQ workflow therefore hands off to the existing Sage process. Once the quote is created, its Sage reference is recorded in THEOS, creating a traceable connection between the operational request and the financial record.
05 · Delivery
Built to move from development into real use.
The application is deployed through Vercel, with the application and database working together as a production system rather than a prototype that only exists locally.
Next.jsReactTypeScriptTailwind CSSSupabasePostgreSQLVercel
How I Work
AI is part of my engineering toolkit.
It isn't a substitute for engineering judgement.
06 · AI-Assisted Development
Use AI to move faster without handing over the thinking.
I used AI as a technical sounding board throughout the development of THEOS — particularly when working through unfamiliar areas, debugging problems, exploring approaches and refining implementation details.
The product decisions, requirements, workflows, UX, business logic, testing and iteration remained mine.
The result was a development process where I could learn quickly, investigate unfamiliar problems and keep moving while still owning the engineering outcome.
Building THEOS taught me that good engineering isn't about designing everything perfectly upfront.
It's about making good decisions, learning quickly and improving the system as reality changes.
The Outcome
The business had a system it didn't have before.
What started as a way to capture client visits became a connected operational platform for managing client information, sales activity, products and quotation requests.
01
Information became central
Client information and activity that had previously been spread across different channels could now be captured and retained in one system.
02
Activity became visible
Representatives had a structured way to record their work, while the business gained a clearer view of client activity and sales engagement.
03
Products became easier to work with
The product catalogue created a structured relationship between machines, assemblies, components and parts, making product information easier to access during the sales process.
04
RFQs became traceable
Quotation requests moved from informal communication into a defined workflow, with the THEOS RFQ remaining linked to the corresponding Sage quote reference.
Reflection
The project changed how I think about building software.
THEOS started because I saw a gap. What I didn't expect was how much building the solution would teach me about product engineering itself.
The hardest problems weren't always technical. They were questions of workflow, information, priorities and understanding what people actually needed.
Building THEOS reinforced what I enjoy most: taking something messy, making sense of it, and turning it into something useful.
I didn't just build a system. I learned how to build around a problem.
← Back to selected workTHEOS Enterprise