Research and Development

Not every need is mature enough to go straight into development. R&D work establishes whether an idea is technically solvable, and at what cost and risk it would be solved.

Research and Development

Whether an idea is ready for development isn't obvious from the start. Research work exists to close that uncertainty: it surfaces whether the work is feasible, which approach fits, and where it's likely to stall. The output of this stage isn't a product — it's a decision on whether to proceed with the project.

We run the work in short cycles. Each cycle tests one assumption, and direction is set based on the result. The order isn't set by the natural flow of the work, but by which unknown is most likely to stop the project.

Are we the right fit?

Not every need has to go through a research stage. If what to do and how to do it are already clear, going straight into development is cheaper. Research earns its place once the cost of uncertainty starts to exceed the cost of development.

Yes, let's talk

  • There's an idea whose solvability isn't clear, and an investment decision hinges on it
  • More than one technical approach is possible, and it's not known which will hold up
  • An IP application is being considered and needs a technical basis established

No, someone else does this better

  • The need is clear, something similar has been done before, and it can be described
  • The expected output is a working product — this stage's output is a decision
  • Budget and timeline are fixed from the start, with no room to change direction based on results

What we do

  • Technical feasibility and solvability assessment
  • Surveying existing solutions and alternative approaches
  • Proof-of-concept work
  • Working prototype development
  • Building measurement and test rigs
  • Performance, durability, and edge-case testing
  • Technical reporting and documentation
  • Technical support for IP application processes

R&D programs we run

Since the pandemic, our focus has been on our own R&D and venture projects. Below are that line's output so far.

IQ Fresco

Our own R&D program 2019–2023

A system that tracks usage intensity in indoor spaces with sensors and ties cleaning schedules and supply refills to that data. Trademark registered; a TÜBİTAK 1507 project proposal has been submitted.

IQ Counter

Our own R&D program 2019–2023

Indoor entry/exit counting and real-time occupancy tracking with a depth-sensing camera. Our second line running in the same period; the accuracy work on the counting side was done here.

NevoLock

TÜBİTAK 1507 2016–2018

An R&D project run under a support program and closed successfully. The resulting technology is protected by a patent and a utility model.

How we proceed

01

Problem definition

We tie what needs solving to a measurable success criterion. A problem with no criterion turns into work whose completion can never be established.

02

Current-state survey

We survey known solutions to the same problem, usable components, and off-the-shelf technologies. This is where we decide what to build ourselves and what to buy.

03

Proof of concept

We test the riskiest assumption with the smallest possible setup. We're not producing a product at this stage; we're seeing whether the approach works.

04

Prototype

We turn the validated concept into a prototype that can work under real conditions. We also assess manufacturability and cost at this stage.

05

Measurement and reporting

We test the prototype against the criteria we set at the start. We report the result in a form that supports the decision to move into development.

Our technical choices

  • The riskiest assumption gets tested first. The order of work isn't set by the natural flow of the workflow; the unknown most likely to stop the project goes first. That way, a negative result shows up before most of the budget has been spent.
  • The measurement rig is part of the work. To be able to say whether an improvement is real, how it will be measured has to be designed from the start. That's why we build the test rig alongside the prototype.
  • The prototype is built so its components can be swapped one by one. When an approach we've tried doesn't work, only the relevant module changes — the whole build doesn't get redone.
  • Approaches that don't work also go on the record. When why a path closed isn't written down, the same experiment gets tried again later. The record of negative results is used in later stages of the project too.
Custom Software Solutions