Skip to main content
Tuğrul Yıldırım

How I scope, build and hand over custom B2B software

You should be able to evaluate the work before committing to a project. The evidence here is practical: detailed case studies, working public products where access is available, free diagnostic tools, dated technical writing and a delivery process with explicit boundaries.

What you can inspect without a sales call

The portfolio separates delivered systems from reference architectures. External links only appear when they lead to a publicly reachable destination; private repositories and unavailable deployments are not presented as public proof.

Case-study scope

Each case describes the records, workflows, roles, system boundaries and technical decisions that can be discussed responsibly. A reference design is labelled as such instead of being presented as a customer result.

Working software and public links

Where a product is open to visitors, its live destination is linked from the case study. A private source repository may still exist, but it is not shown as a public link unless anonymous access has been checked.

Tools you can run

The integration health check and iPaaS-versus-custom TCO calculator produce an immediate result without registration. They also show how assumptions and decision rules are made visible in a real interface.

Authored technical material

Articles include an author, publication date and implementation detail. You can follow new writing through the public RSS feed without creating an account.

Open the RSS feed →

Start with the work itself

These examples show different kinds of product and operational work. Read the case before following any external destination; the case explains what the project demonstrates and what remains private.

A delivery process built around decisions you can verify

The exact artifacts depend on the project, but ownership, acceptance and handover are agreed before implementation expands.

  1. 1

    Map the workflow

    Follow a representative record through users, decisions, exceptions and existing systems.

  2. 2

    Define the boundary

    Agree authoritative data, permissions, integrations, acceptance criteria and explicit exclusions.

  3. 3

    Release in reviewable slices

    Deliver the smallest complete path, test the important rules and review it with representative data.

  4. 4

    Hand over deliberately

    Provide the agreed source, deployment and operational material, then confirm who owns routine support.

Typical project artifacts

  • Scope and assumptions: users, workflows, integrations, dependencies and exclusions.
  • Data and ownership: important records, authoritative systems and permission rules.
  • Acceptance evidence: agreed scenarios, automated tests where appropriate and review notes.
  • Handover: project-specific source ownership after the agreed commercial terms, plus deployment and operating notes appropriate to scope.

Boundaries stated before work begins

  • No performance percentage is promised without a baseline and a way to measure it.
  • No production access is requested when sanitized records, logs or diagrams are enough for the current step.
  • Third-party costs, licences, data cleanup and ongoing support are separated from the build scope.
  • Confidential client information is not turned into a public claim simply to make a case study look stronger.

Bring one real workflow to the conversation

A representative quote, order, stock exception or integration failure is enough to begin. I will use it to ask focused questions about scope and fit.

Discuss Your Workflow