Deep-Tech Development: When Your Problem Is the Algorithm, Not the UI

4 out of 10 project inquiries we receive aren't really software problems. They're algorithm problems wearing a software costume.

The founder describes a dashboard. They talk about features, user flows, and design. But buried in the brief is a sentence like "the system needs to detect velocity drift in real-time" or "we need to classify images with 95% accuracy." That sentence is the actual project. Everything else is a wrapper.

Key Takeaways > - Most agencies price deep-tech work like CRUD apps. The cost model is completely different. > - ProxControl's velocity drift algorithm was the product. The UI took 2 days. > - If your project's core value comes from a calculation, classification, or signal - you need algorithm engineers, not full-stack developers.

What Deep-Tech Actually Means

We use "deep-tech" to describe projects where the core problem is computational, not presentational.

A SaaS dashboard is a presentation problem. You're taking data and making it look good. The engineering challenge is real but well-understood. Thousands of agencies can build dashboards.

A painting detection system that measures spray velocity drift in an industrial factory - that's a computation problem. The data is noisy. The environment is unpredictable. The algorithm needs to work in real-time with sensor data that wasn't designed for this purpose.

The difference matters because the development process is completely different.

With a dashboard, you design screens, write components, and connect APIs. Linear progress. You can estimate with confidence.

With an algorithm, you hypothesize, test, fail, iterate, and test again. Progress is nonlinear. You might solve the core problem in day 3 or day 30. You might discover the approach is wrong and need to start over.

ProxControl: The Project That Taught Us Everything

ProxControl manufactures industrial spray-paint systems. Their problem: measuring how consistently operators paint surfaces. Too fast, the coating is thin. Too slow, it drips. They needed software that could detect velocity drift in real-time and alert operators.

Here's what a typical agency would have done: spent 4 weeks building a beautiful real-time dashboard with charts, user management, and notification systems. Then spent 1 week "integrating the algorithm" and discovered the algorithm doesn't work with real sensor data.

Here's what we did: spent 3 weeks on the algorithm. Then spent 2 days building the interface around it.

The algorithm was the product. Not the UI. Not the notifications. Not the admin panel.

Phase 1: Core velocity measurement We started with raw accelerometer data from painting robots. The data was noisy - vibrations, pauses between strokes, direction changes. A naive velocity calculation was useless because it treated every sensor reading as meaningful.

We built a signal processing pipeline: noise filtering, stroke segmentation, directional analysis, and velocity computation. Each step had to be validated against ground truth data from the factory floor.

This isn't work you can estimate in hours. You estimate it in hypotheses. We had 5 approaches to stroke segmentation. Three failed. The fourth worked in controlled conditions but broke with real-world data. The fifth worked.

Phase 2: False positive reduction The core algorithm worked, but it flagged too many false positives. An operator pausing to reload paint triggered a velocity drift alert. Direction changes at the edge of a surface triggered alerts. The system was accurate but unusable.

We reduced false positives by 90% through hysteresis thresholds, debounce windows, and movement gating. This phase was pure algorithm refinement. Zero UI work.

How to Tell If Your Project Is a Deep-Tech Problem

Here's our litmus test. Answer these three questions:

1. Could a junior developer build the core feature? If yes, it's not deep-tech. A junior developer can build authentication, CRUD operations, payment integration, and dashboards. They can't build a signal processing pipeline or a machine learning classifier.

2. Does the project require domain expertise beyond software? ProxControl required us to understand industrial painting processes, accelerometer physics, and quality control standards. That's domain knowledge that no amount of React experience provides.

3. Is the hardest part invisible to the user? The ProxControl operator sees a simple gauge. Green means good. Red means adjust. The user sees 2% of the engineering work. The other 98% is hidden in the algorithm.

If you answered yes to two or three of these, you have a deep-tech project. Price it accordingly. Staff it accordingly.

Why Most Agencies Get Deep-Tech Wrong

The standard agency model is optimized for CRUD applications. Hire designers, frontend developers, and backend developers. Assign them to projects. Bill by the hour or by the sprint.

This model breaks for deep-tech because:

The team composition is wrong. You don't need 3 frontend developers and a designer. You need 1 algorithm engineer who understands the domain, 1 backend engineer who can build the data pipeline, and maybe a frontend developer for the last 10% of the project.

The estimation model is wrong. You can't estimate algorithm R&D the same way you estimate a landing page. "Build login page: 8 hours" is a reliable estimate. "Develop velocity measurement algorithm: ??? hours" is not. Agencies that apply CRUD estimation to deep-tech either massively overquote or massively underdeliver.

The review process is wrong. Sprint demos for deep-tech look different. Week 2 might be: "We tested 3 approaches to noise filtering. Two failed. Here's what we learned and what we're trying next." That doesn't fit neatly into a Jira board.

We price deep-tech from EUR 20k for approximately 1 month of work. That's not because the work is less. It's because the team is smaller and more specialized. One or two people doing focused research and implementation, not a 6-person team building screens.

The Contrarian Take: Most "AI Products" Are Actually CRUD Apps

Here's an opinion that loses us leads: 80% of projects pitched to us as "AI-powered" are really CRUD apps with an API call to OpenAI.

If your product calls GPT-4 to summarize text or classify inputs, you don't have a deep-tech problem. You have an API integration problem. Any competent full-stack developer can build it.

Deep-tech means you're building the intelligence, not renting it. You're training custom models. You're processing signals that commercial APIs don't handle. You're writing algorithms that don't exist as libraries.

We turn away "AI" projects that are really API wrappers. Not because they're bad projects - they're just not deep-tech. They should be priced and staffed as standard SaaS builds, not as algorithm engineering.

If you're calling an API, you need a SaaS agency. If you're building the thing the API would call, you need deep-tech engineers.

What a Deep-Tech Engagement Looks Like

Our deep-tech process is fundamentally different from our SaaS process.

Week 1: Problem definition We sit with the client's domain experts. Not their product manager. Their engineers, scientists, or operators. We need to understand the physics, the data, and the constraints. We define success metrics: accuracy, speed, false positive rate, latency.

Weeks 2-3: Research and prototyping We test multiple approaches in parallel. We write throwaway code. We validate against real data, not synthetic data. Every approach is documented with results.

Week 4: Implementation Once we have a validated approach, we productionize it. Clean code, proper error handling, monitoring, and deployment. This is the only phase that looks like normal software development.

Ongoing: Calibration Deep-tech products need tuning after deployment. Real-world data reveals edge cases that test data didn't cover. We typically include 2-4 weeks of post-deployment calibration in our estimates.

When to Build Custom vs Buy Off-the-Shelf

Not every algorithm needs to be custom. Here's our decision framework:

Build custom when: - No commercial solution handles your specific data or domain - Accuracy requirements exceed what general-purpose tools provide - Latency requirements rule out cloud API calls - The algorithm is your competitive advantage

Buy off-the-shelf when: - A commercial API or library solves 80%+ of your problem - Accuracy of 85-90% is acceptable - Latency isn't critical - The intelligence layer isn't your differentiator

ProxControl was a clear build-custom case. No commercial velocity measurement library handles industrial spray-paint accelerometer data. The algorithm was their entire value proposition.

A SaaS that summarizes meeting notes? Use an API. The summary isn't your differentiator. The workflow around it is.

Frequently Asked Questions

How much does deep-tech development cost?

Our deep-tech engagements start at EUR 20k for approximately 1 month. Pricing depends on the complexity of the algorithm, the quality and availability of training/test data, and whether we need domain-specific expertise. Simple algorithm work (data transformation, basic classification) sits at the lower end. Signal processing, computer vision, and real-time systems sit higher.

How do you estimate work when the algorithm is uncertain?

We scope in phases. Phase 1 is always research and validation - we prove the approach works with real data. Phase 2 is productionization. If Phase 1 shows the approach won't work, the client pays for Phase 1 only and gets a detailed report on what we tried and why it failed. This limits risk for everyone.

Do you build the full product or just the algorithm?

Both. For ProxControl, we built the algorithm and the minimal interface around it. For other clients, we've delivered just the algorithm as an API that their existing team integrates. It depends on what you need. We price accordingly.

What programming languages and frameworks do you use for deep-tech?

Python for research and prototyping (NumPy, SciPy, scikit-learn). Rust or C++ when performance matters. TypeScript for APIs and interfaces. The language follows the problem. We've never picked a language first and forced the problem into it.

*Have a problem that's more algorithm than UI? Book a 30-minute call to discuss whether it's a deep-tech engagement or a standard build. Or see our Deep-Tech Engineering service for details on what we deliver.*