Least privilege, and a log that proves it.
Authentication, permissions, tenant isolation and audit logging, built in from the first commit. Retrofitting access control is how a small application turns into an expensive one.
- Deny by default
- access is granted, not assumed
- Audit logged
- who did what, and when
- Tested
- authorisation covered by the suite
Who this is for
You probably need this if…
01
Everyone is an administrator
It was easier that way at five people. At thirty it means a junior hire on their second day can delete the customer table.
02
You cannot answer who changed that
A record is wrong, nobody knows who edited it or when, and there is no log anywhere to consult about it.
03
A customer sent a security questionnaire
Forty questions about controls you have almost certainly not written down anywhere, due back by the end of next week.
What this covers
The work, in detail.
7 capabilities
01
Authentication
Sessions, MFA, passkeys and SSO, with the account recovery flows designed deliberately rather than left to a password reset email.
02
Roles & permissions
Role and attribute-based access enforced on the server, because a hidden button is a design choice and not a permission.
03
Tenant isolation
Row-level security, so one customer's query cannot return another customer's data, enforced by the database rather than by developer discipline.
04
Audit logging
An append-only record of who did what and when, retained and queryable for the day somebody actually asks you about it.
05
Secrets management
Credentials in a managed store, scoped to what needs them, rotated on a schedule, and never committed to the repository.
06
Dependency & supply chain
Advisory monitoring against your real dependency tree, with anything urgent applied out of cycle instead of waiting for a release window.
07
Compliance readiness
Mapping your controls to what SOC 2 or HIPAA will ask for, and being straight about the gap. We prepare you for an audit; we do not perform one.
How we approach it
Positions we actually hold.
Opinions cost something to have. These are the ones we would argue for on your project, including where they make the work slower.
01
Deny by default
Nothing is reachable until access is explicitly granted. The opposite default is how data reaches people who were never being malicious about it.
02
Enforce at the database
Row-level security means a forgotten filter in application code still cannot return another tenant's rows. Discipline fails eventually; constraints do not.
03
Authorisation gets tests
Every role is covered by tests asserting what it cannot do. Permission bugs are completely silent right up until they are a headline.
04
Log what you will be asked about
Access, changes, exports and permission grants. Append-only, retained, and searchable before anyone needs it rather than after.
Technology
What we work with.
Defaults, not requirements. If you already run something else and have a team who knows it, we work in yours.
- Identity
- Auth.js, Auth0, Okta, SAML & OIDC, passkeys
- Authorisation
- RBAC & ABAC, PostgreSQL row-level security
- Secrets
- AWS Secrets Manager, Doppler, scoped credentials
- Monitoring
- Dependency advisories, audit trails, anomaly alerts
Where this shows up in delivery
- Sill ships authentication, role-based permissions, multi-tenancy and audit logging as its foundation layer, already running in production.
- Tenant isolation on shipped builds is enforced with row-level security rather than application-level filtering.
- Every engagement inherits authorisation tests rather than writing them from scratch, which is the reason they reliably exist.
Bought as part of
This practice is never sold on its own. It is quoted inside one of the engagements above, as part of a single number.
Proof
Where we have actually done this.
Projects we designed, shipped and wrote up. Each one names the decision that was genuinely hard to get right.
Questions
What people ask about security & access.
- Can you get us SOC 2 certified?
- No, and no engineering firm can. Certification comes from a licensed auditor. What we do is build and document the controls so that the audit becomes a review rather than a rebuild.
- Is HIPAA something you handle?
- We build to the technical safeguards: encryption, access control, audit logging, and BAAs with the infrastructure providers. Your compliance counsel owns the policy side, and that division of responsibility should be explicit from day one.
- Do you do penetration testing?
- We do not perform the test itself. We prepare for one and remediate the findings, which is the part that genuinely needs the engineers who know the codebase.
- What if you find something serious in our existing system?
- You hear about it the day we find it, privately and in writing, with a severity assessment and an estimate of what fixing it would take. That holds whether or not you engage us to do the fixing.
Related reading
Written on this, by us.
Data & Integration · 7 min read
Multi-Location Is a Permissions Problem Wearing an Inventory Costume
Adding multi-site support with a location column works until one person holds different authority at two sites. Then it quietly leaks data.
Cloud & Security · 7 min read
What SOC 2 Actually Asks For, and What No Engineering Firm Can Sell You
A customer sends a security questionnaire and suddenly compliance is urgent. Here is what the controls actually are, and where the line sits between preparation and certification.
Tell us what you’re trying to build.
Describe the problem in your own words. We’ll come back within one business day with a scope, a number and a date.
Phone
+1 (407) 796-2376Reply time
One business day, from an engineer
Based in
Orlando, Florida · serving the United States
What happens next
- A reply within one business day, from an engineer
- A thirty-minute call, with no qualifying call before it
- A written scope and a fixed number, if it fits