Software Consulting · Ankara

Before you write anything, decide what you won't write.Software Consulting

An outside view on technology decisions: assessing the current system, a roadmap and a reasoned buy-or-build decision.

Current-state analysisRoadmapArchitecture reviewVendor selectionTechnical auditHand-over plan

The question we're asked most in consulting is "which technology should we use?". In practice another question is more decisive: do we really have to build this, or should we install something that already exists?

We give the same answer even when we won't be the ones writing the system. In a project that starts with the wrong decision, who writes it doesn't change the outcome.

If this sounds familiar

  • You can't decide whether to move to a new system or develop the current one.
  • The software quotes you've received are very different and can't be compared.
  • Nobody knows how solid the current software is, or who wrote what.
  • A software project keeps dragging on and the reason isn't clear.

What it covers

Current system assessmentWhat exists, how solid it is, whether it can be migrated. Code, architecture and operations are reviewed together.
Build / buy decisionComparing an off-the-shelf product with custom development; hand-over readiness is weighed as much as cost.
RoadmapSequenced, measurable steps. Each step should deliver value on its own.
Technical auditReviewing existing software: security, maintenance burden and risky areas.
Vendor assessmentTechnically comparing the proposals received and listing the questions that need asking.
Hand-over planThe steps needed to transfer a system to another team or organization.

Example scenarios

Illustrative examples; the specifics are worked out during discovery at your site.

DecisionBuild or buyReady-made options and custom development are set side by side on total cost, transferability and lock-in.
AuditHealth check of inherited softwareCode, database, security and deployment setup are reviewed; risks are ranked by priority and the first actions are identified.
ProcurementEvaluating quotesQuotes are compared against the same scope; questions for suppliers are prepared for items left out or left vague.

What we deliver

  • Report with findings, options and a reasoned recommendation
  • Prioritised risk list
  • Roadmap of sequenced, measurable steps
  • Supplier comparison table where needed
  • Presentation in which the report is reviewed with management

How we proceed

1 · ListeningHow the problem shows up, who it affects and what has been tried so far.
2 · ReviewA concrete review of the system, data and processes.
3 · ReportFindings, options and a reasoned recommendation — not a single path, but options with their consequences.
4 · Implementation supportOptional: technical support in putting the decision into practice.

When it's the right choice

  • You want an independent view before a major software decision.
  • Access to source code and a running environment can be provided.
  • You want the outcome of the report to be independent of who will implement it.

When it's not the right choice

  • If you only expect a decision that has already been made to be rubber-stamped.
  • If access to the system and data for review can't be given.

Frequently asked

Will you end up recommending your own product?

When it fits, we recommend it and say so openly. When it doesn't, we say that too — if a ready-made product or another vendor is the better answer, that's what the report says.

You didn't write our current software — will you still review it?

Yes. Most technical audits are carried out on systems written by other teams. Access to the source code and a running environment is enough.

Let's talk about this.

We'll listen to your current situation and work out together where to start.