Skip to content

Ankara

Custom software for organisations in Ankara

Ankara work is process-heavy and document-heavy. Software succeeds there when it models who may see what and who approves what — before anyone designs a screen.

Process and approval flowsRoles and permissionsAudit loggingRemote · one contact

Permissions are the design, not a feature

In nearly every institutional project we run, the longest conversation is about authorisation. The person who creates a record, the person who approves it and the person who reports on it are different people. Software that does not reflect that either exposes everything to everyone — a finding waiting to happen — or blocks work entirely.

So the role and permission matrix is designed first, before screens. A permission layer added afterwards is the most expensive change a business system can undergo, because every screen and every query must be revisited.

The second recurring theme is the document: output that behaves like a formal record, can be traced, and cannot be silently altered after the fact. Audit logging is not a nice-to-have here; it is the foundation the rest sits on.

Put these in the contract

They decide whether the system survives its first audit.

  • Who produces the permission matrix? Projects that start without one get rewritten at go-live.
  • What is logged? Which action, by whom, when — the first thing any inspection asks for.
  • Where does the data live? Server location and backup location are two separate compliance questions.
  • Which legacy systems must it talk to? There is almost always one, and the integration cost belongs in the estimate.

Frequently asked

Do you have an office in Ankara?

No — we work remotely and we do not claim otherwise. Meetings run by phone and online, with screen sharing where useful. If your procurement process requires on-site meetings, that needs discussing at the outset; a city-based supplier may fit you better and we are comfortable saying so.

Can you support a tender or procurement process?

On the technical side we can: reading technical specifications, assessing whether the technical requirements can be met, and preparing the technical part of a proposal. What we do not do is procurement law, qualification certificates or legal drafting — that needs your own advisor. We also never present a certificate we do not hold; we take the same position on penetration testing authorisation.

Can the software run on our own servers?

For organisations with a regulatory obligation to host on their own infrastructure, we discuss a separate deployment and handover model. Our default is to run it on servers we operate and continuously patch, because OS patches, certificates, firewall rules and verified backups are links in one chain and splitting that chain across parties weakens it. Either way, your data can be exported at any time.

What exactly do you cover on data-protection compliance?

The technical measures, built and documented: role-based access limits, encryption in transit and at rest, audit logging, retention periods with a deletion mechanism, and monitoring that makes breach detection possible. Legal documents — privacy notices, consent records, processor agreements — are your lawyer’s work. Be cautious with suppliers who blur that line; a software firm cannot assume legal liability for your compliance.

Describe the process you want to fix

Tell us which work is slowing you down and who approves what. Sometimes the answer is configuring what you already own, and we will say so.