A grant-funded study is being administered through a Retool board nobody can audit
Custom internal tools for a Kingston research lab, health spinout or public-sector team cost $40k to $95k over three to six months. Build them when a Retool board or Airtable base now carries clinical, grant or resident data that needs real access control, an audit log, and PHIPA-grade handling that low-code cannot enforce.
Retool, Airtable and a stack of spreadsheets are how most Kingston teams start, and that is fine until the data inside them becomes regulated. A Queen's-linked lab spins up an Airtable to track study participants; six months later it holds health information governed by Ontario's PHIPA, accessed through one shared login, with no record of who saw what. A public-sector team runs intake on a spreadsheet that three departments edit at once. The tool did not change; the stakes did.
The wall you hit is not features, it is governance. Airtable cannot give you per-field permissions a privacy officer will sign off on. Retool's audit trail is shallow when an ethics board asks who accessed a participant record on a given date. The moment a study coordinator leaves and you cannot prove their access was revoked, the convenient low-code tool becomes a liability that the academic IT department was never resourced to fix.
Why the usual tools struggle in Kingston
- Clinical or participant data in Airtable accessed through one shared login
- No per-user audit trail when an ethics board or privacy officer asks who saw what
- PHIPA-grade access control low-code platforms cannot enforce
- Spreadsheet intake edited by multiple departments with no version control
What a custom internal tools build changes
Once data is regulated, the tool needs to enforce governance, not just display data. A custom internal tool gives every user a real account, every action a logged trail, and every field the permission a privacy officer requires. It is usually faster and cheaper than you fear, because the scope is narrow: replace the one board that now carries risk, not rebuild everything. The payoff is that the next audit or access request takes minutes instead of a frightening afternoon.
- A low-code tool now holds clinical, participant or resident data
- You cannot answer who accessed a record on a given date
- A privacy officer or ethics board has flagged the current tool
- Shared logins make offboarding a security gap
- The data is non-sensitive and Airtable's permissions are enough
- The workflow changes weekly and low-code's flexibility wins
- You have no regulated data and no audit obligations
- A short-lived project that will not outlive the spreadsheet
- Per-user accounts and real access control instead of one shared Retool login
- Full audit trail ready for an ethics board or privacy officer
- PHIPA-aligned handling of participant and health data
- Workflow logic enforced in software, not in a coordinator's memory
- Narrow, affordable scope that replaces only the risky tool
- You lose the speed of changing an Airtable column in seconds
- Someone must own the tool once the low-code platform is gone
- Small scope can creep; without discipline a $40k tool becomes a $90k one
- Custom tools need hosting and patching the SaaS used to handle
The features that matter for Kingston
What we build under internal tools in Kingston
The engagements Kingston teams bring us most often:
Internal Tools pricing in Kingston: the real numbers
| Project scope | Typical cost | Timeline |
|---|---|---|
| Single regulated-tool replacement | $40k to $60k | 3 to 4 months |
| Multi-workflow internal platform | $65k to $95k | 4 to 6 months |
| Hosting, support and access reviews | $10k to $20k | ongoing |
From kickoff to launch: the schedule
Exactly what you get
A replacement for the one tool that now carries risk: real accounts, field-level permissions, and an audit log a privacy officer will accept. The deliverable is defensibility, you can answer who accessed what and when in minutes, and offboarding a study coordinator no longer leaves a hole.
How to choose a developer in Kingston
Ask the team how they would handle Ontario PHIPA data and have them show an audit trail from real work. The right partner scopes tight: replace the regulated board, not the whole stack. Make sure the tool plays with your custom-software and business-intelligence-dashboards layer so data flows once it is governed. A team that shrugs at privacy obligations is the wrong team for a research-city build.
- !Treats access control as a login screen; ask about field-level permissions and audit logs
- !No PHIPA awareness; ask how they handle Ontario health data
- !Wants to rebuild everything; ask why the scope is not just the risky tool
- !No offboarding plan; ask how a departing coordinator loses access
- !Cannot show an audit trail they built; ask to see one
If internal tools is on the roadmap, custom software, wordpress, accounting usually follow within the year. Budget them as one conversation.
Rohan advises mid-market and enterprise teams on ERP, CRM and custom software, and has led delivery on dozens of business-software builds.
Writes for Digital Heroes, shipping business software for 2,000+ brands across 55+ countries since 2017.
Frequently asked questions
Isn't Retool fine if we just add permissions?
Retool adds basic roles, but field-level control and a deep, immutable audit trail that satisfies an ethics board are where low-code platforms strain. For regulated clinical or participant data, a privacy officer often needs more than Retool exposes.
How do we keep this from ballooning in scope?
Replace only the tool that now carries risk. A disciplined build targets the single regulated workflow, ships in three to four months, and resists the urge to rebuild every spreadsheet at once.
Does this have to be PHIPA-compliant?
If it touches Ontario health information, yes. That means real accounts, audit logging, consent and retention handling, and revocable access, the things shared-login Airtable cannot give you.
What happens to our existing Airtable data?
It migrates into the custom tool during the build, with a parallel-run period so you confirm parity before switching off the low-code version.