What is the Türksat shelf, and why does it matter?
Being listed in Türksat's pre-approved software catalogue for public institutions is one of the fastest public-sector sales channels for Turkish B2B SaaS players. Instead of selling to institutions one by one: a single master contract, institutions pay a functional-use fee, Türksat invoices and brokers, and the software vendor maintains the product.
KDM (Corporate Governance & Risk Module) was placed on this shelf in Q4 2025. Looking back, here are the architectural and operational decisions we learned:
1. Multi-tenant isolation: how isolated is the tenant?
The first question is always: is institution data in one database or separate ones? Three levels:
- Pure shared: Single DB,
tenant_idcolumn. Cheapest. Lowest compliance posture. - Schema-per-tenant: Isolation at PostgreSQL schema level. Medium cost.
- DB-per-tenant: Each tenant gets its own DB. Most expensive, most secure.
In KDM we went hybrid: application data is schema-per-tenant; audit logs + personal data under KVKK are DB-per-tenant. In practice: if an inspector comes, we can open only that institution's audit DB; even though application DBs are shared, PII sits in a safer place.
2. Branding layer: how deep
By Türksat shelf requirement, each institution wants to use the product under its own name. Not "U2 Soft KDM personalised for Institution X" — but "Institution X Internal Audit System". We designed the branding layer on three levels:
- Logo + colour: SaaS classic. Theme JSON, uploaded by institution.
- Name + domain: Subdomain or full custom domain (DNS CNAME). Email sent from the institution's own domain.
- Report templates: Each institution's official correspondence format differs. Every PDF report renders from the institution's template.
3. Version management: which institution on which version?
The least discussed but most critical issue. If one institution wants a new feature, do the others automatically get it? The answer is usually: no. Public institutions prefer to hold the "stable" thing.
In KDM, we kept the feature-flag system tenant-scoped. Core engine has a single version, but features open/close per institution. When a new feature ships, the toggle opens for 1–2 institutions first; if it stabilises in 3 months, it becomes default for all.
4. Operational: who supports?
Türksat is the broker, it doesn't support end users. The software vendor (us) does. This forced us to set up the customer success team from day zero. Our SLA targets: P1 incidents 1 hour, P2 4 hours, P3 1 business day.
5. Pricing: who pays, how?
On the Türksat shelf, pricing is a single line item: number of users × monthly fee. Complex pricing (modules, API calls) doesn't fit the shelf model. Accepting this simplified our product model too: each institution gets the same package, doesn't differentiate functionally, only data/user count varies.
Takeaway
The key design decision for the white-label shelf model: "One product, many identities, isolated data". Set up these three right and the sales channel grows exponentially. Get it wrong and every new institution means manual work. The Türksat shelf opens B2B SaaS sales to the public sector; but if your architecture isn't ready for multi-tenancy, the distribution channel will kill you.