Engineering
Quality and security.
In every software system we build.
Quality means checking that the system does the job you need. Security means controlling who can access its data and actions. Both guide every Zetesis project.
This page explains the decisions and checks behind the work. Public writeups and runnable demonstrations let you inspect examples before getting in touch.
01 Access & data
Put the boundary where access happens.
Permissions should reflect what each user and service needs to do. A hidden button or an instruction in an AI prompt cannot enforce access to a database.
- Who can reach the data?
- Identify the roles, service accounts, and sensitive data involved. Separate access where those responsibilities differ.
- Where does sensitive information go?
- Map the data the system needs, where it is stored, and which external services receive it. Keep confidential material out of public writeups and demonstrations.
- What should be refused?
- Check denied requests at the permission boundary as well as the actions that are meant to succeed.
The permissions writeup shows why this matters: a change to the prompt would have left the underlying credentials in place.
02 Testing & review
Check the work against the requirements.
Quality starts with a scope that both sides can review. Testing focuses on the core user journeys, important edge cases, and the consequences of a failure.
- Does the agreed flow work?
- Review the deliverable against its requirements, including inputs, outputs, and relevant error states.
- What needs attention before release?
- Use the review to identify defects and discuss limitations. The testing approach and depth depend on the project.
You review completed milestones before their payments are due. A free 30-day warranty after full transfer covers both system-critical and minor bugs in the agreed deliverable. We review the contract's coverage and correction process at the final meeting.
Read the warranty coverage and terms03 External services
Account for the services the system relies on.
An integration brings its own permissions, costs, and failure modes. Those belong in the technical decisions and the conversation about running the system.
- What happens when a request fails?
- Consider timeouts, unavailable services, and repeated actions. Where relevant, check how the system reports the problem and whether retrying can duplicate work.
- Who operates and pays for it?
- Identify the required accounts and ongoing provider charges. Client operation and optional maintenance have different responsibilities, agreed before handover.
04 Handover
Make ownership practical.
Ownership includes the source repository and a clear plan for the accounts the system uses. Infrastructure is set up in your name where practical, with remaining transfers discussed from the start.
- What will you receive?
- Ownership of the custom project code and source repository transfers after final payment. We walk through setup, account transfers, and how to take the project forward.
- What happens after transfer?
- You can operate the system or arrange project-specific monthly maintenance. Either way, a free 30-day warranty covers both system-critical and minor bugs in the agreed deliverable, with details defined in your project contract.
Discuss your project.
We work primarily through private referrals and review new inquiries for fit. Start with a high-level introduction; an NDA comes before confidential scoping.