Hired to track budgets. Expanded into building the systems behind the work.

The starting point

I was hired to handle budgeting on the project-development side. There was no operating framework to inherit and no formal onboarding, so the first job was understanding how work actually moved.

• Information was fragmented. Job status, vendor follow-ups and project details lived in people's memory, on paper, in personal task lists, in email and on whiteboards.
• Budgets were hard to rely on. An earlier tracking effort in a general-purpose tool didn't produce project balances leadership could plan from, and bank transactions and receipts were recorded inconsistently.
• No shared daily view. Leadership couldn't see, in one place, what needed to happen on each project today.

These were process gaps, not people problems — a small company growing faster than its systems.

How the system works

One platform, organized around how the company works rather than around software modules:

Live for internal staff (October 2026)

• Work orders
• Maintenance intake
• Leases & rent
• Bank transactions
• Project balances
• Monthly budget requests
• Reports & Excel export
• Role home pages
• Two-factor sign-in
• Audit history
• Scheduled-job monitoring

• Personal workspaces. Each person lands on a page built for their job — a phone-first work queue, an assigned-work view for the field lead, a financial overview for finance, a leases view for compliance.
• Access by role, enforced by the database. Hiding a menu is never treated as security; every restriction is enforced server-side, and people can request extra access that an administrator approves.
• History you can trust. Every meaningful change records who did it and when, written by the system, never by the browser.

Adoption and the feedback loop

Rollout happened one role at a time — operations coordination, field lead, finance and leadership, then compliance — each with their own sign-in, two-factor setup and home workspace.

The most useful work often came straight from users:

• A wrong assignment in the field was traced to a label that implied responsibility the data model didn't have. I fixed both — the wording and the model, so the responsible person is chosen when work is created.
• An access request went unnoticed because nothing notified the people who could approve it. The next day, requests notified exactly the administrators allowed to decide them.
• Unit navigation proved confusing while onboarding a new colleague. Two releases the same day made each unit open its current lease directly — and I accepted the change after testing it that afternoon.
• Training on the newer finance features. After a training session in October, the operations coordinator used them, including Bank Transactions, without problems. That's my report of one person's experience, not a measured result.

Results

• Delivered: one shared system replaced scattered sources for work orders, leases, rent, project balances and reports, and the old tools were retired.
• Adopted: office, field, finance and leadership staff were onboarded by role, each with their own sign-in and home page.
• Efficiency: in my observation colleagues work more efficiently, but it hasn't been measured, so I don't put a number on it.
• Scope: my responsibilities grew from budget tracking to owning the company's operating systems.

Limits and lessons

• Measure before you change. I didn't capture baselines early, so the impact is qualitative. For the next workflow I'll record tasks, follow-ups and time spent first.
• Say what a safeguard can't do. The job watcher runs inside the database, so it can't notice the scheduler itself stopping. That limit is written down and an outside check is planned, rather than calling the system fully monitored.
• Security is ongoing. An internal security assessment is published inside the product. It has not been independently reviewed; that review is planned before any external users.
• Prove definitions cheaply first. Starting in a spreadsheet let the company agree what a "project balance" means before it was built into software.
• AI speed needs discipline. Fast AI implementation only helped because every change was small, reviewed, verified and written down. How that works →