Contact us
Who We Build For
AI Solutions
Start
Build
Run
Before you start
How We Work
Transparent. A team that stays. Your IP: code, trained weights and data are yours by contract.
Read how we work
MusicTech

It-Jim develops music technology for creative production, including music recognition, generation and voice processing.

Go to page
Startups

Software development services for startups. It-Jim helps founders build MVPs, AI solutions, and scalable products from idea to market launch.

Go to page

Not sure where to start?

Talk to an expert

02 · Research

Technical research: a two-week AI feasibility study on your data

A two-week AI feasibility study on your recordings, at a fixed price. Two or three candidate models run on your data with accuracy measured rather than estimated, a catalogue of where they fail, a cloud or on-device decision backed by numbers, and a proof of concept roadmap with a fixed price. It ends with a written go or no-go.

TimelineTwo weeksPriceFixed price
Send what you haveWhat you get
A tennis serve clip and three candidate models with their accuracy on it; Model B gets the go
How we workTransparent. A team that stays. Your IP.
Read how we work
  • You own the IP

    Code, trained weights and your data are yours by contract. We sign an NDA before you send anything.

  • A team that stays

    Knowledge is documented and shared across the team, so nothing depends on one person. You can ask to change anyone on the team, and the work carries on.

  • Transparent work

    The whole team is in your Slack and on your calls. Regular demos and reports, and we tell you about problems as soon as we see them.

Who it is for

Is this the right step for you?

  • You promised a camera feature to customers or investors and have no proof yet that it can be measured.
  • Your current model counts wrong and nobody on the team can say why.
  • You are choosing between an SDK, a cloud vision API and a model of your own.
  • Your CTO has already researched the problem with Claude or ChatGPT and now needs numbers from real footage.

Proof

Results from past projects

Floodlit amateur football pitch at night, cut along the halfway line and laced back together like a bootCase studyFanaty

Automated Panorama Stitching for Football

  • Every match stitched into one full-pitch panorama automatically
  • 4K panorama at 30 FPS in a cloud pipeline, with no GPU bill as new fields join
  • Video processing 8× faster after the first consultation
Computer VisionSports TechRead the case
Pardigm cortisol tracking appCase studyPardigm

Hormone Tracking Made Easy

93%+ accuracy reading cortisol test strips with a phone camera in real-life lighting

What you get

Technical research: the deliverables

  1. 01

    Numbers on your own recordings: two or three candidate models, each scored on a test set we build from your footage.

  2. 02

    A catalogue of where it breaks: clips of failures on fast motion, low light, occlusion and cheap cameras, drawn from your data and from 200+ past projects.

  3. 03

    Cloud or device, decided with evidence: the best model converted to CoreML or TFLite, timed on a low-end Android and an older iPhone, with the accuracy lost in conversion measured. Cost per user at your scale for cloud, on-device and a per-user SDK.

  4. 04

    A data audit: whether your data is usable, how much more you need, what labelling will cost, and annotation guidelines.

  5. 05

    A licence check of every model and dataset we recommend, so the code and IP can pass to you.

  6. 06

    A technical report, an architecture outline and a PoC roadmap with a fixed price and timeline.

  7. 07

    An online demo deployed in the cloud, so your team can try the best candidate on new recordings.

How it works

From first message to done

  1. 1

    Week 1: data audit, test set, baseline accuracy on the candidate models, failure catalogue.

  2. 2

    Week 2: on-device conversion and timing, cost model, report, demo deployment.

  3. 3

    Day 10: a read-out call with the engineers who did the work. The go or no-go arrives in writing the same day.

TimelineTwo weeks
PriceFixed price

About 100 engineering hours. It starts after the free assessment.

Done when

A written go or no-go with a priced plan for the proof of concept. A no is a valid result. In our experience close to half of camera features that look feasible on paper fail on real recordings, and finding that out at a fixed price is the point.

What comes next

When the report says go and your pilots or investors need to see it work on your data, the next step is the Proof of concept.

03Proof of concept

Compared with the alternative

A capable engineer with a chatbot can list candidate models, read papers and draft an architecture. What that setup cannot do is run the models on your footage with labelled data and GPUs, show you where they fail on cheap phones, measure what conversion to CoreML costs in accuracy, check the licence of every dataset, or commit to a PoC price that the same team will deliver. Those are the parts you are paying for.

Questions

What teams ask about technical research

Yes, when the assessment finds the task well understood. Otherwise the research is what makes the PoC price fixed.

Recordings from real users or sessions, in the conditions the feature will meet. If you have none, we tell you what to film.

You do. The report, the demo code and the test set are yours, whatever you decide next.

How we work

What you can count on

How will we know the AI is any good?

Success metrics are agreed before a line of code, and the report scores against them. No technical background is needed to read the result.

What if the concept does not work?

You get a written no with the evidence. Expectations are set at the start; in our experience close to half of ideas stop here.

Are you reinventing the wheel?

No. Candidates are open-source and foundation models first. The research measures where out of the box stops being enough.

Next step

Send what you have. Verdict in a day.

Start with the free assessment. If the task is measurable, the research is the next step.

  1. 1
    You send a spec and a few recordings

    A paragraph on the feature, a link to clips or sensor logs, the platforms. NDA first if you need one.

  2. 2
    An engineer reviews it

    The CTO or a domain expert goes through the measurement, the conditions and the platforms.

  3. 3
    You get the verdict within a day

    Whether the feature can be measured, the risks we see, and the recommended next step, in writing.