Twenty years of building systems that get attacked on day one taught us four things. None of them are principles in the abstract — they're the operating patterns we keep returning to because they're the difference between systems that hold and systems that fail in the field.
Security is the first design constraint, not the audit at the end.
Every product ships under adversarial review before launch. We design as if the system will be attacked on day one — because the systems we build for are attacked on day one. Importer compliance regimes, fertilizer authentication at national scale, donor verification across hundreds of thousands of households: each one has motivated adversaries from the moment it goes live.
That means threat modeling sits next to the architecture diagram, not after it. It means the security team is in the room when the data model gets drawn, not when the staging environment goes up. It means red-team review is a gate, not a checkbox.
For BMQAS Security, our healthcare-IoT and medical-device work, every device-to-cloud channel goes through adversarial review before a single unit ships. The threat model assumes the device has already been compromised. The platform survives that assumption because that's how it was designed.
Designs that fail in the village, on shaky 3G, or in real hospitals are failed designs — even if they looked good on paper.
A surprising amount of enterprise software is built for the conditions of the building it's designed in: fast laptops, gigabit internet, English-speaking users, predictable power. The deployments that matter to us happen nowhere near that building.
NAAFCO's fertilizer dealers authenticate UID-level products from rural districts on intermittent 3G. BRAC field workers log Ultra Poor Graduation household visits on entry-level Androids in places where the next charging point may be a day's walk away. Hospitality front desks process check-ins during PMS outages they didn't ask for and can't escalate. If the system needs the demo conditions to work, it doesn't work.
We design for the worst credible operating environment first and let the optimistic conditions inherit from it, never the other way around. Offline-first is not a feature toggle; it's the floor.
Shohay's field workflows for BRAC sync opportunistically over 2G/3G, queue locally for days when they have to, and resolve conflicts at the household level on reconnect. The supervisor reviewing today's visits doesn't know — and shouldn't need to know — which ones were captured offline.
Our engineers understand how NGOs operate, how hospitality front desks work, how telecom signaling behaves.
You cannot build verified delivery for a UPG program if you don't know how a household visit is actually structured — what the supervisor checks, what gets contested, what a "missed visit" means in the field, what fraud looks like when it happens. You cannot build a hotel check-in system if you don't know what a walk-in is, why a held-room matters, how the front desk talks to housekeeping, what happens when the PMS goes down on a Saturday night.
That literacy lives in the engineering team — not in a separate product or BA layer that gets translated down. The person writing the data model knows why the program officer needs that field, because they've watched the program officer use it.
Two decades of building inside these verticals — telecom with Grameenphone and Robi, NGO operations with BRAC, hospitality with Jazzware deployed at thousands of hotels, healthcare with medical IoT — taught us this is not the kind of literacy you can acquire from a discovery interview.
The engineers on the BRAC UPG digitalization spent weeks shadowing supervisors and field workers before the data model was finalized. The decision to model a "visit" as a contestable claim rather than an immutable record came from that fieldwork. It changed everything about how the audit trail was built.
We stay with clients for years, inheriting the consequences of our own architectural decisions. That keeps us honest.
Most software vendors design once and leave. The architectural shortcuts that look reasonable in year one become structural debt in year three, and someone else inherits the cleanup. We don't have that escape hatch — we run our systems in production with our customers for years, sometimes more than a decade, and the decisions we made early are the decisions we live with.
That changes how the early decisions get made. You design differently when you know you'll still be on the receiving end of the pager in 2030. You're more conservative about coupling, more skeptical of cleverness, more willing to spend the extra week now to avoid the extra year of toil later.
It also changes how we hand things off. Documentation is for our own future operators. Runbooks are for the on-call engineer we'll hire two years from now. The platform isn't done when it ships; it's done when it's still healthy three years in.
The Jazzware RT-1000 ESB we built for hospitality PBX/PMS integration is still running at thousands of hotels worldwide — more than a decade after the first deployment. Same architecture, evolved continuously. The team that maintains it overlaps substantially with the team that designed it.
It belongs in Approach because that's where it operates. The certifications below describe the floor; the principles above describe what we do when no one is auditing.
Security, availability, and confidentiality controls audited against the AICPA Trust Services Criteria. Type I complete; Type II observation window underway.
Information security management system operated to ISO 27001 controls. Formal certification in scope for 2026.
Regional data residency for EU, US, and South Asia deployments. Customer data does not cross regional boundaries without explicit configuration.
AES-256 at rest, TLS 1.3 in transit, envelope encryption for sensitive fields. Key management via cloud-native KMS with customer-managed key support for regulated tiers.
Role-based access with least-privilege defaults, hardware MFA for production access, immutable audit logs with tamper-evident chain, quarterly access review.
Continuous SAST/DAST in CI, third-party penetration testing annually plus before major releases, public disclosure program for responsible reporting.
Long before SurroundApps was the company name on the door, this team was shipping production trust infrastructure at national scale. The deployments below aren't a logo wall — they're where the practice came from.
Production identity-verification pipelines for two of Bangladesh's largest mobile operators, processing millions of subscriber registrations under regulator-mandated KYC. The identity primitives running in today's verifiable-credential issuance trace directly to this work.
Audit and verification systems for nonprofit programs operating across hundreds of field offices. Taught us how to design tamper-evident records that hold up under donor review and program audit — the foundation of what later became Shohay's audit layer.
Jazzware RT-1000 deployed at thousands of hotels worldwide for real-time integration between phone systems, property management, and guest services. Where we learned what enterprise integration looks like when "down for an hour" is unacceptable.
The senior engineers on our team came through delivery roles at companies whose names matter to enterprise buyers — not as résumé decoration, but as carriers of operating standards we still hold the team to. PwC, BPCL, and Technuf joined the picture as we moved into supply-chain trust work.
Security work on healthcare devices where the threat model is non-negotiable: a compromised infusion pump or remote-monitoring device is a clinical incident, not a customer support ticket. BMQAS Security's healthcare-device practice grew out of this work and feeds Ontor Care today.
The fastest way to test our approach is to put a real problem in front of us. Bring the messy one — the deployment with intermittent connectivity, the audit that has to survive an adversary, the integration the last vendor walked away from.
Talk to us