Gentek. Validated and listed.
Gentek is a technology company that builds software. We run their AWS — the partner status, the technical review, the Marketplace listings, and the infrastructure under the SaaS platforms they ship. They own the product. We own the ground it stands on.
One relationship, three pieces of work.
The partner track and the platform builds ran as separate scopes. Each one stands alone; together they are the reason Gentek can sell on AWS rather than merely run there.
Validated, reviewed, and listed
The AWS side of Gentek, owned end to end, so their engineers stayed on product.
The problem
A software company can build well and still be invisible on AWS. Validated software partner status, the Foundational Technical Review, and a Marketplace listing are three separate gates, each assessed by someone outside the company, each with its own evidence requirements and none of them satisfied by writing good code.
Gentek builds software. The AWS estate underneath it, and the evidence that the estate is sound, is what they brought us in for.
What we did
- Took them through software partner validation AWS validated software partner status is a technical validation AWS runs against the solution, not a form the partner fills in about itself. The architecture has to survive being read by someone with no stake in the answer.
- Prepared and passed the technical review The Foundational Technical Review submitted, the findings closed, and approval obtained. The review is the gate for a Marketplace listing, so failing it quietly is not a state you can stay in.
- Ran the Marketplace presence Their SaaS solutions prepared and submitted as listings, so what customers can subscribe to matches what was actually reviewed.
- Held the boundary between the two teams Zynostack owns the AWS estate and everything that proves it sound. Gentek owns application development. Written into the scope rather than left to goodwill, which is the only version of a split responsibility that survives a deadline.
LedgerIQ, on new ground
A greenfield AWS foundation for a finance ledger platform, where the driver was latency under production load.
The problem
LedgerIQ is a finance-sector platform, and finance is a domain where a slow response is treated as a broken one. The requirement was not simply a place to run: it was a foundation that stays responsive under production load and can be reasoned about afterwards.
Greenfield sounds like the easy case. It is the case where every default you accept becomes permanent, because nothing is yet depending on it loudly enough to be worth changing later.
What we did
- Laid the foundation before the workloads Account baseline, network layout, IAM strategy, CloudTrail and GuardDuty, with the architecture decisions written down as records rather than remembered. Every resource defined as code from the first commit.
- Segmented the network properly Public, private and isolated tiers across multiple availability zones, with redundant outbound routing, security groups, network ACLs and flow logs. Isolation designed at the start costs a diagram; retrofitted, it costs a migration.
- Made the platform observable CloudWatch across the stack: log groups with retention that someone chose, metric filters, composite alarms rather than a wall of single ones, a dashboard per workload, and anomaly detection. An alarm nobody can act on is noise with a pager attached.
- Put the application on Fargate ECS on Fargate with image repositories under lifecycle policies, load balancer integration, application auto scaling, and configuration through Secrets Manager. No instances to patch, no hosts to lose.
- Secured storage and the database by default S3 with versioning, encryption under customer-managed keys, least-privilege policies, lifecycle rules and public access blocked. PostgreSQL on Amazon RDS Multi-AZ with encryption, automated backups, enhanced monitoring and database authentication through IAM.
- Named what we were not doing Application code deployment, pipelines, and containerizing the application stayed with Gentek, in writing, in the scope. A boundary that is only understood is a boundary that moves.
eInvoice, and the signing boundary
A multi-tenant platform that files signed tax documents, built so it cannot hold a customer signing key.
The problem
Egyptian e-invoicing regulation requires tax documents to carry a signature produced with the taxpayer’s own seal, held on a hardware token issued to them. A multi-tenant service filing on behalf of many taxpayers therefore has a problem with no comfortable answer: it must produce valid signatures without ever holding the keys that make them.
Any arrangement where the platform could sign on a customer’s behalf, even in principle, even with a policy forbidding it, is commercially disqualifying. Policies are not a security boundary. They are a description of what people intend to do.
What we did
- Made the boundary structural rather than procedural The platform builds the canonical bytes and a digest. An agent on the customer premises re-derives that digest independently, signs against the hardware token there, and returns the signature, which the platform verifies against the tenant’s registered tax number. No operator action, support path, or configuration change on the platform produces a private key, because the platform is never on the side of the boundary where one exists.
- Enrolled the agent outbound-only A single-use enrolment token exchanged for a short-lived session credential, over an outbound connection. The customer opens no inbound firewall rule, which is both easier to get approved and less to defend.
- Assumed every dependency would fail The agent goes offline, a signature fails verification, a certificate approaches expiry, the tax authority is unavailable. Documents hold in a signed, queued state and resubmit under an idempotency key, so recovery never becomes a duplicate filing.
- Built the tenant-isolation baseline Envelope encryption under a customer-managed KMS key, configuration held as encrypted parameters and resolved when a task starts, and CloudTrail, GuardDuty, Config and Security Hub running across the account rather than switched on for a review.
- Ran the platform on managed services Application, API, workers, accounts and an operations console on Fargate, with PostgreSQL on Amazon RDS Multi-AZ, Redis on ElastiCache, and versioned, delete-protected S3 for documents. No servers, no bastion, no guest operating system to patch.
- Required a plan review before every change The whole environment in Terraform with remote state and locking, deployed from CI, and no apply without a reviewed plan. Production that can be changed by hand is production nobody can describe.