Starting point
Contract data was stored as PDFs. Because the content wasn't available in structured form, workflows across several departments ran manually—or were blocked.
Deniz Kosan-Aytac · Prototyping for internal solutions
Before your team builds: certainty it's the right thing.
When important workflows run on manual effort because data is locked in PDFs, spreadsheets and disconnected systems, the most expensive answer is a project that solves the wrong problem. I make sure everyone involved means the same right thing—visible as a clickable prototype, validated with your developers, before a single line of production code is written.
In 6–12 weeks: a validated prototype, a feasibility check with your developers and a concrete implementation plan.
01 — The problem
Does this sound familiar?
- Important data is locked in PDFs, spreadsheets and disconnected systems—not where your workflows need it.
- Teams hand work off manually and reconcile the same information again and again.
- Requirements live in documents—and every department reads something different into them.
- No one can say with confidence what is technically and organizationally feasible.
02 — Outcome
What you get.
-
Clarity on workflows, data and systems
One shared picture: how the work actually happens, where data lives and which source is authoritative.
-
Two or three solution paths
Concrete options with their strengths, risks and dependencies—including what your current systems can already do.
-
A tested clickable prototype
A realistic design everyone involved can test and confirm—built from the start so it can be carried over into production software.
-
Feasibility check and handover
Reviewed with your developers—functionally, technically and organizationally—and handed over as a validated blueprint with a concrete implementation plan. Your team doesn't start from zero.
Everyone reads a requirements document differently. No one misreads a prototype. Once everyone involved has seen and confirmed the same design, the target is binding—the discussion about what was actually meant happens before implementation, not after.
03 — Approach
How I work.
-
Understand the real work
Review concrete cases, decisions and handoffs with the people involved—across department lines.
-
Clarify data and systems
Map where data lives, which source is authoritative and what your systems can already do.
-
Bring the right people together
Align business teams, IT and leadership on one shared problem and goal.
-
Prototype and test solution paths
Turn two or three plausible paths into a clickable prototype and test with the people affected.
-
Validate with your developers and hand over
Check feasibility with developers and architects, then hand over so your team can implement directly.
04 — Case study
B2B company · 1,000+ employees
From PDFs in an archive to an implemented solution.
Approach
Collected real cases across departments and aligned stakeholders on one shared picture. Clarified where the data lives, which source is authoritative and what the existing systems could already do. Formulated a stable capability for the system landscape, then used a clickable prototype to identify and test concrete use cases with the departments—validated with the developers.
Result
The solution was implemented by the internal development team. The prototype was built from the start so it could be carried over into production code within the platform architecture—the handover was a transfer, not a rebuild.
05 — When to call
How you know it's time.
What matters isn't industry or department—sales, operations or service—but the situation: an initiative needs clarity before more money and trust flow into it.
An important workflow depends on a few people
It works—until that person is out or the case deviates from the standard. Little is documented, less is shared.
The systems are there—the workflow runs around them
Salesforce, Odoo or a homegrown back office: whatever the system doesn't cover ends up in spreadsheets and inboxes. Often the existing landscape can do more than it does today.
An automation or AI idea is on the table
But no one can assess it with confidence. Before the decision, you need a shared picture and a testable design.
Business teams and IT talk past each other
Requirements go back and forth—and still the wrong thing gets built, or nothing at all.
The IT backlog is years long
Departments wait, shadow spreadsheets grow. Clarify what actually needs to be built—and what doesn't.
06 — Evidence
Customer-facing experience and hands-on building.
I don't just write concepts—I build. My approach combines customer-facing B2B SaaS experience with hands-on prototyping and products I've shipped myself.
Shipped product
ANCBuddy
An independent, paid macOS app I designed, built, launched and support end to end.
Working prototype
LernPilot
A working AI tutoring prototype for WhatsApp, built to explore explanations, exercises and feedback in a conversational flow.
Roughly 500–700 customer conversations, demos and pitches across customer-facing B2B SaaS roles.
Customer Success and Product at DataGuard; today, Product Management at LOFINO / JobRad.
07 — About
I work where functions meet.
I connect Product, Operations, Sales, Service, Data and Technology. My role is to bring the right people together, turn scattered knowledge about real work into one shared picture and make solutions tangible early—so your organization invests on solid ground. AI is one of the tools I use to work faster—not the promise itself.
Alongside my Product Management role at LOFINO / JobRad, I take on a small number of external projects where an internal workflow needs clarity before implementation.
08 — Contact
Bring a workflow that takes too much manual effort.
If data is stuck and a workflow spans teams and tools: let's find out which solution holds—and test it as a prototype before you invest in implementation.