Building Tinker Relay
Every growing services business eventually runs into the same problem: the business grows faster than the systems connecting it.
Sales knows what was promised, but delivery has to reconstruct the details. Project teams know what has changed, but finance may only discover the commercial impact later. Client updates are scattered across email, chat and meetings. Managers build reports from systems that were never designed to share the same version of the truth.
We experienced those problems ourselves.
So we built Tinker Relay.
Relay began as a relatively straightforward CRM and project management project. Over time, it became something much more important: the operational layer connecting how Tinker Digital manages relationships, sales, projects, finance, support and client collaboration.
It is, quite simply, the engine behind the work.
We started with how the business actually works
One of the earliest decisions we made was not to begin with dashboards or interfaces.
We started by mapping the business.
A client relationship does not begin when a project starts. It begins much earlier, usually with a conversation or opportunity, and continues through proposals, agreements, delivery, billing, support and, ideally, a long-term relationship.
Those stages are connected.
A proposal may become a project. A change in project scope can affect the timeline and budget. An approved deliverable can trigger the next commercial step. A support request may eventually become an ongoing service agreement.
Treating each of these as a separate application creates fragmentation.
Relay was designed around the opposite idea: the business should operate as one connected system.
That meant thinking in terms of workflows rather than isolated features.
From CRM to an operating platform
The original scope covered CRM, project management, sales, finance, support and client collaboration.
As we worked through it, the boundaries between those areas became increasingly artificial.
Sales needed visibility into what eventually became delivery.
Delivery needed access to the commercial context behind a project.
Finance needed to understand approved changes and project progress.
Clients needed useful visibility without being exposed to internal operations.
Management needed information from all of these areas without assembling it manually.
Relay gradually became the shared operational layer between them.
Today, it connects the journey from opportunity to revenue and from delivery to long-term client support:
Lead → Opportunity → Proposal → Project → Delivery → Billing → Support → Renewal
Around that flow sit approvals, communication, change management, reporting, resource planning and client collaboration.
The objective is simple: important information should move with the work.
Building the client experience first
One of the most useful decisions we made was to build the client experience early.
It forced us to answer an important question:
What should a client be able to see and do, and what should remain internal?
Clients need visibility.
They should be able to understand progress, review milestones, approve deliverables, provide requested information, access documents, follow financial information relevant to them and communicate with the team.
But visibility is not the same as operational control.
Internal teams still need their own workspace for planning, assignments, scheduling, internal discussions and delivery management.
That distinction became an important design principle throughout Relay.
The internal system contains the operational truth. The client experience presents the relevant, approved view of that information.
This allowed us to make the platform collaborative without exposing the complexity of running the business behind it.
Access is part of the product
As Relay expanded, permissions quickly became more than an administrative feature.
Different teams need fundamentally different views of the same business.
Finance does not need the same controls as Engineering. Sales should not automatically have access to every operational action. Clients must only see the accounts and projects relevant to them.
We therefore designed access around responsibilities and capabilities rather than simply hiding menu items.
Teams such as Sales, Finance, Project Management, Engineering, Marketing and Administration can inherit the access they need through team membership, while individual exceptions remain possible where required.
More importantly, those rules are enforced throughout the system rather than relying on what the interface chooses to display.
Good permission systems should disappear into the product. People see the information and actions relevant to their work without constantly thinking about access control.
Workflows matter more than forms
One of the easiest mistakes when building business software is creating a collection of forms around database records.
Create a customer.
Create a proposal.
Create a project.
Create an invoice.
Technically, the system works.
Operationally, very little has improved.
The real value comes from connecting those actions.
An accepted proposal should be able to inform project setup. An approved change should carry its commercial and scheduling implications forward. A request from a client should move through the appropriate team until it reaches a clear outcome.
Each action should leave enough context for the next person to understand what happened and what needs to happen next.
That is where automation becomes genuinely useful.
Not because a system performs more actions, but because fewer people have to manually move information between them.
Finance belongs inside the workflow
Financial information is often treated as something that happens after delivery.
In practice, finance is connected to almost every stage of a client relationship.
Proposals establish commercial expectations. Scope changes affect budgets. Project progress influences billing. Support agreements create recurring obligations. Renewals depend on both commercial and operational history.
Relay brings those relationships closer together.
The goal is not to replace accounting systems. It is to make sure the operational side of the business understands the financial consequences of the decisions being made.
That gives teams a much clearer picture of the relationship between work, commitments and revenue.
The platform also had to work for us
We build software for other businesses, but Relay is different in one important respect:
we are one of its users.
That changes the development process.
When something takes too many clicks, we experience it.
When information is difficult to find, our own team feels the friction.
When a workflow does not match how work actually happens, we discover it quickly.
As the platform grew, much of our work shifted from adding features to removing friction.
Large screens became focused workflows. Navigation became simpler. Client-facing terminology became clearer. Project management became more visual and contextual. Notifications became more useful. Information that once required several systems became available from a single operational view.
Using Relay internally continually exposes the difference between a feature that technically exists and a feature that genuinely helps someone do their job.
That feedback loop has become one of the most valuable parts of the product.
Security had to be designed into the system
A platform containing client information, financial records, project files and internal operations cannot treat security as an afterthought.
Security influenced Relay from the beginning: how users authenticate, how access is scoped, how files are handled, how important actions are recorded and how different users interact with the same underlying information.
We deliberately placed those controls at the system level rather than relying on the interface alone.
The broader lesson is straightforward:
If a business platform becomes a source of operational truth, trust in that platform becomes part of the product itself.
Reliability, access control, auditability and data protection are not infrastructure concerns hidden somewhere underneath the application. They directly affect whether people are willing to run their business through it.
Building Relay changed how we think about internal software
There is a temptation to treat internal systems as secondary products.
We have reached the opposite conclusion.
The systems a company uses internally directly affect how well that company serves its customers.
Poor internal tools create duplicated work, slower responses, missing information and unnecessary coordination.
Good systems quietly remove those problems.
Relay increasingly allows us to spend less time managing the mechanics of work and more time actually doing it.
And because we use it ourselves, improvements made for Tinker often become lessons we can apply when building systems for our clients.
What we learned
Several lessons have stood out during the development of Relay.
First, do not automate a process you do not understand. Mapping the real workflow is more important than building the interface around it.
Second, business systems become valuable when information moves between teams. A CRM, project-management tool and finance system are individually useful. Their real value appears when the handoffs between them disappear.
Third, permissions are part of product design. Different people should experience the same platform differently based on their responsibilities.
Fourth, client visibility and internal operations should not be confused. Clients need transparency without being exposed to the machinery required to deliver the work.
Fifth, using your own product changes what you build. Internal friction becomes impossible to ignore when your own team encounters it every day.
And finally, automation is not about removing people from the process. It is about removing unnecessary coordination so people can focus on the decisions and work that actually require them.
The engine behind the work
Relay has grown well beyond the CRM and project-management system we originally set out to build.
It now connects much of the operational journey inside Tinker Digital: from the first opportunity, through proposals and delivery, to finance, support and ongoing client relationships.
There will always be more to improve. That is part of building software around a living business.
But the objective remains the same.
One place where work connects.
One operational truth shared across teams.
Clear ownership at every stage.
Less time moving information between systems and more time creating value for clients.
We build automation and software for other businesses every day.
With Relay, we turned that same thinking inward.
Tinker Relay. The engine behind the work.