Choosing a development partner: IP, contracts and cost

A note on who is writing this

We are a development company, so this article is not disinterested. We have tried to make it useful anyway, including the sections on when not to outsource and on how to evaluate suppliers like us, because a client who engages us on unclear terms is a problem for both of us.

Where the advice happens to describe what we do, that is because we arrived at these positions by having the opposite happen. Treat the whole thing as a checklist to use on us as much as on anyone else.

The engagement options

Ways to get engineering work done

Arrangement	Suits	Costs
In-house team	Core, continuing work; knowledge you must keep	Hiring time, fixed cost, narrow skill coverage on a small team
Individual contractors	A specific skill gap for a defined period	You provide management and integration; availability is fragile
Engineering consultancy	Multi-discipline projects with a defined outcome	Higher rate; knowledge transfer must be planned
Offshore development team	Sustained work where rate matters	Communication overhead; hardware access is awkward
Product company with a platform	Fastest to something working	Constrained to their architecture; dependency afterwards
A combination	Common and frequently sensible	Somebody internal must own the whole

The last row is worth stating plainly: whichever route, one internal person needs to own the outcome. Not necessarily doing engineering, but able to answer questions, make decisions and accept the result. Projects without that person drift regardless of how good the supplier is, because every question becomes a delay.

Intellectual property

This is where the most expensive misunderstandings happen, and they happen because both sides assume the obvious answer is shared.

Background IP is what each side brought. A supplier with a tested power supply design, a firmware framework or an internal toolchain will use it, which is usually to your benefit. It normally stays theirs — and you need a licence to use it in your product, including after the relationship ends. A contract that transfers the design but not the right to use the supplier’s embedded framework transfers something you cannot ship.

Foreground IP is what the project creates, and it is the part most contracts address. Two details beyond ownership: when it transfers, since assignment on final payment means a dispute leaves you owning nothing, and whether it covers the design rationale and documentation rather than only the files.

Third-party and open-source components belong to neither side. No supplier can assign what they do not own, and the practical question is whether the licence terms are compatible with how you intend to sell. Some open-source licences carry conditions that surprise people when a product is distributed commercially. This should be checked against a bill of materials for the software, which is the same artefact the security regulation article argues for on different grounds.

Tools, fixtures and data is the forgotten category and frequently the one that binds you. Test fixtures, production tooling, build environments, signing keys and accumulated test records are what allow a different party to continue the work. Owning a schematic while somebody else holds the only test fixture and the only working build environment is a weaker position than it appears.

Reading a quotation

Quotations for the same project routinely differ by a factor of three, which almost always means they are quoting different work rather than different prices.

What to establish before comparing numbers:

• How many design iterations are assumed? One board revision or three changes the figure substantially, and one is rarely realistic.
• Is design for manufacture included, or does the design arrive needing another pass before it can be built?
• Is pre-compliance included? Its absence is a common reason a quotation looks competitive.
• What documentation is delivered? Source files or exports; a handover pack or a working product.
• What happens when requirements change? They will. The mechanism matters more than the rate.
• Who buys components and equipment, and at whose risk?
• What support follows delivery, for how long, at what cost?
• What is explicitly excluded? The most informative question, and the one a thorough quotation answers without being asked.

A quotation at half the others is not usually a bargain. It normally assumes fewer iterations, excludes work you will need, or reflects a misunderstanding of the requirement — and the third is the worst, because the gap emerges mid-project when changing supplier is expensive.

Why estimates are genuinely difficult

Worth understanding rather than treating as evasion. Estimating development work is hard because the work includes finding out what the work is. A requirement to “monitor machine temperature” could be a two-week job or a six-month one depending on access, accuracy, environment, certification and integration — none of which is usually settled when the estimate is requested.

This is why a definition phase is worth paying for: a short, bounded piece of work producing a specification, an architecture and a realistic estimate. It costs a fraction of the project, and it converts a guess into a number with reasoning behind it. A supplier who quotes a firm price for a loosely described project has either added a large contingency or will be back with change requests.

Getting a useful specification out of your own organisation

The commonest obstacle to a well-run project is not finding a supplier but arriving with a clear enough description of what is wanted. Most organisations find this harder than expected, because the knowledge is distributed and partly tacit.

A specification does not need to be long. What it needs to settle:

• What problem this solves, and for whom. One paragraph. If it cannot be written, the project is not ready.
• What the product must do, separated from what would be desirable. Being honest about that distinction is most of the value, because everything drifts into the first list otherwise.
• The environment. Temperature, humidity, vibration, washdown, who installs it, who maintains it, how long it must last.
• Volumes and target cost. Both change the architecture, and neither can be accommodated once the design exists.
• Markets and certification, because these shape the radio, the supply and the schedule.
• Interfaces. What it connects to, in what format, owned by whom.
• Constraints that are genuinely fixed: a mounting footprint, an existing connector, a date tied to something real.
• What success looks like, in terms someone could check.

Two techniques help when this stalls. Write the user documentation first — describing how somebody installs and uses the product forces the vague parts into the open. And describe the second product as well as the first, briefly, because knowing that variants are coming changes architectural decisions that are expensive to revisit.

If this cannot be produced internally, that is itself useful information: it usually means either that the requirement is genuinely unsettled, in which case a definition phase is the right first purchase, or that the people who understand the need have not yet been in the same room.

Fixed price and time-based work

Who carries which risk

	Fixed price	Time and materials
Estimation risk	Supplier	Customer
Priced for	Includes contingency you pay whether used or not	Actual effort
Response to change	Resistant; each change is a negotiation	Absorbs change naturally
Incentive	To finish quickly, which cuts both ways	Requires trust and visibility
Suits	Well-defined work with a clear specification	Exploratory work, or work that will evolve
Fails when	Requirements were not actually clear	Nobody is tracking scope

The arrangement we would generally suggest is a hybrid: a fixed-price definition phase, then fixed-price work for what that phase specified, with time-based work for anything genuinely exploratory. This puts fixed pricing where it works — on defined scope — rather than on a guess.

Whatever the model, visibility matters more than the pricing structure. Regular demonstrations of working functionality, honest reporting of what is not working, and early warning of problems are what distinguish a project you can manage from one you discover late. A supplier whose reports are uniformly positive until a deadline slips is telling you something.

What a project actually costs

We cannot quote without a specification, and the shape of the cost is consistent enough to be useful for budgeting — particularly the items regularly left out.

Where a development budget goes

Item	Share	Notes
Definition and architecture	5–15%	Cheapest place to change your mind; frequently skipped
Hardware design	20–30%	What people picture when they say development
Firmware	25–40%	Routinely underestimated, particularly connectivity and updates
Mechanical	10–20%	Higher with tooling or sealing requirements
Prototype builds	5–10%	Boards, components, assembly, across several iterations
Test and validation	10–20%	Fixtures, environmental testing, debugging
Certification	Varies widely	Multiplies with radios and markets; see the certification article
Documentation and handover	5–10%	First thing cut, and what determines who can maintain it
Project management	5–10%	Real work whether or not it appears as a line

Three observations. Firmware is usually the largest single item and is consistently underestimated, because the visible functionality is a fraction of the work — connectivity, error handling, update mechanisms, provisioning and diagnostics are most of it. Certification can exceed the hardware design cost for a multi-radio product sold into several markets, and it is frequently absent from early budgets entirely. And the costs after first delivery are missing from this table: integration, field issues, revisions and support continue, and a budget covering only the build tends to run out just as the product becomes real.

The pattern that causes most disputes

Almost every difficult commercial conversation in development traces back to the same structure: a price agreed against an understanding that was not written down, then a divergence about whether something is included or additional.

It is rarely bad faith. The client believed a feature was obviously part of “monitoring the machine”; the supplier priced the specification as written. Both are being honest and they are describing different projects.

What prevents it is unglamorous: a written specification, however short, that both sides have read and can point at, and a change mechanism agreed before the first change. Not a formal process — for a small project a shared document and an email confirming each change is plenty. What matters is that a record exists which neither side is reconstructing from memory six months later.

Working with a team in another place

Distributed development is normal now and works well or badly for reasons that are mostly not technical.

• Overlap hours decide the pace. Some conversations need to be conversations. Three or four hours of overlap is enough; none means every question costs a day.
• Written communication becomes the record. Teams that write decisions down survive the gap; teams that rely on conversation lose context across time zones.
• Decision authority must be explicit. If every small question waits for someone in another time zone, progress runs at one decision a day.
• Somebody must physically hold the hardware. This is the hard constraint with electronics. Remote debugging of a physical fault is slow, and shipping boards between countries adds days and customs.
• Test equipment has to be somewhere. A team without an oscilloscope on the same desk as the board is limited regardless of skill.
• Time zones affect testing too. A build handed over at end of day in one place is tested while the authors sleep, which is an advantage if the feedback loop is set up for it and a frustration otherwise.

The arrangement that works most reliably for hardware is co-locating the physical work — boards, instruments and the people who debug them — while distributing what genuinely can be distributed, such as firmware modules with good test coverage. Splitting hardware debugging across time zones is where distributed projects most often stall.

On rates: a lower rate is a real saving and not the whole picture. Specification effort, review time, communication overhead and the risk of rework from a misunderstanding are costs too, and they scale with how much context has to be transferred. The calculation usually favours distributed teams for sustained, well-specified work and favours proximity for exploratory work where the requirements are still moving.

Signals worth noticing

In both directions, since a bad fit is uncomfortable for everyone.

What to watch for in a supplier, and what they watch for in you

Concerning in a supplier	Concerning in a client
A firm price for a vague requirement	No written requirement, and reluctance to produce one
No stated limits on what they take on	An immovable date with no scope flexibility
Reluctance to discuss handover	Nobody internally able to answer questions
Uniformly positive reports	Requirements arriving continuously, none dropped
Won’t let you speak to engineers	Decisions reversed after being agreed
Claims of certification they cannot evidence	Budget covering the build and nothing after it
No process for changes	Payment linked to milestones nobody defined
Estimates that never move as scope grows	Expectation that a prototype is nearly a product

The last row on the client side is worth expanding because it is so common and so consequential. A working prototype frequently looks finished, and the remaining work — manufacturability, certification, reliability, support — is invisible from outside. A supplier who explains that this is most of the remaining cost is being straight with you, not padding. The detail is in prototype to volume production.

Assessing capability

Case studies and client lists are weak evidence: they show selected successes, and a logo indicates a transaction rather than a good outcome. More useful:

• Ask to speak to an engineer, not only to whoever handles sales. Ten minutes of technical conversation reveals more than any document.
• Ask about a project that went badly and what changed afterwards. Everyone has one. An answer that blames the client entirely is informative in its own way.
• Ask what they would not take on. Honest limits are a sign of experience.
• Ask how they estimate, and what they do when an estimate proves wrong.
• Ask who will do the work. Whether the people in the meeting are the people on the project.
• Ask to see a handover pack from a previous project, redacted. This shows what you will actually receive better than any promise.
• Give a small piece of work first where possible. A short paid review or a feasibility study costs little and shows how an organisation actually works.

The last is the most reliable signal available. How a supplier handles a two-week piece of work — communication, documentation, whether they raise problems early — predicts how they will handle a six-month one.

Structuring the engagement

How a project is divided and paid for shapes behaviour more than any clause about quality.

Milestones that mean something

Milestones tied to dates measure the calendar. Milestones tied to demonstrable outcomes measure progress, and the difference matters when a project is in trouble.

A milestone worth having names something you can observe: a board that powers up and communicates, firmware demonstrating the core function on real hardware, a unit passing pre-compliance with margin, a documented handover pack delivered. Each is either achieved or not, which means an honest conversation happens at the milestone rather than at the end.

Two cautions. Acceptance criteria belong in the milestone definition, written when both sides are calm — “works correctly” is not a criterion. And milestones should not be so large that the first honest checkpoint is months away; a project with a single delivery at the end has no mechanism for discovering trouble early.

Payment

Arrangements that tend to work: an initial payment covering the definition phase, then payments against achieved milestones, with a final portion on handover rather than on first delivery. That last detail matters, because documentation and handover are the items most likely to be neglected if everything has already been paid.

What causes trouble: payment entirely on completion, which puts all cash-flow risk on the supplier and tends to produce corner-cutting near the end; and payment entirely in advance, which removes any structural incentive. Neither side benefits from an arrangement where one party carries all the exposure.

Also worth settling: what happens if the project stops. Projects get cancelled for reasons unrelated to the engineering — funding, strategy, a market moving. An agreed position on work in progress, on what is handed over and on what is paid prevents an ordinary business event from becoming a dispute.

Liability, and what it is reasonable to expect

Development contracts usually cap the supplier’s liability, commonly at the project value. Clients sometimes read this as an attempt to avoid responsibility; it is closer to a structural necessity, and understanding why leads to a better arrangement than arguing about the number.

A supplier paid a modest sum to design a component cannot underwrite unlimited consequential loss from a product recall or a production stoppage. No small engineering company could carry that exposure, and one that agrees to is either not reading the clause or not able to honour it. The cap is part of what makes the work possible at the price.

What is reasonable to expect instead: that the supplier will fix defects in their own work, within a defined period, at their own cost. That is a warranty on the engineering rather than insurance against business consequences, and it is the appropriate instrument. Where genuine consequential exposure exists — a product whose failure would be expensive or hazardous — the answers are insurance, a different risk allocation priced accordingly, and verification effort proportionate to the stakes, not a clause transferring risk to a party who cannot absorb it.

It is worth confirming that a supplier carries professional indemnity insurance and what it covers. As with the rest of this section, the specifics belong with a qualified adviser.

Confidentiality

Mutual non-disclosure agreements are routine and worth reading rather than signing reflexively. The points that matter in practice:

• Mutual rather than one-way. Both sides will see things worth protecting.
• Carve-outs for prior knowledge. A supplier cannot unlearn general engineering practice, and an agreement purporting to prevent them using ordinary skill is unworkable and will be ignored.
• A sensible duration. Perpetual confidentiality on everything is difficult to honour and therefore weak.
• Consistency with the IP terms. The two documents must not contradict each other, which they frequently do when drawn up separately.
• Subcontractors. If the supplier uses specialists, the agreement needs to permit that under equivalent terms.

On patents, one practical note rather than legal advice: public disclosure before filing can affect patentability in many jurisdictions, and a demonstration, a trade show or a published article can count. If patent protection matters, that conversation belongs before the work is shown to anyone, and with someone qualified.

Running the project well

Most of what determines the outcome happens after the contract is signed, and a good deal of it is the client’s responsibility.

• Answer questions quickly. A blocked supplier either waits or assumes, and assumptions become rework. This single factor distinguishes projects that run smoothly more than any other.
• Send one voice. Conflicting direction from several people is a reliable way to build the wrong thing.
• See working hardware regularly. A demonstration every few weeks surfaces misunderstandings while they are cheap.
• Let bad news travel. If problems are met with blame, the next one arrives later and larger.
• Be honest about fixed constraints. A real deadline, a real cost target or a real size limit should be stated at the start, when the design can accommodate it.
• Track changes, including small ones. Scope rarely grows through one large addition; it grows through twenty small reasonable ones.
• Keep a decision log. A short record of what was decided and why, which becomes valuable precisely when the people involved have moved on.

On the supplier side, what you should expect: regular honest reporting including what is not working, early warning rather than late surprise, questions asked rather than assumptions made, and documentation produced as the work proceeds rather than assembled at the end.

What happens if the supplier disappears

Small engineering companies are acquired, change direction, lose the individual who knew your product, or close. This is a normal commercial risk and it is manageable if considered in advance rather than discovered.

• Hold the source yourself, continuously. Not promised at the end — in your own repository throughout, updated as work proceeds. This single arrangement removes most of the exposure.
• Make sure the build reproduces. Holding source you cannot turn into the shipped binary is a weaker position than it looks. Verify this during the project by building it yourself at least once.
• Know where the physical items are. Fixtures, tooling, programmed devices, spare boards.
• Keep accounts in your own name where possible — cloud services, certificate authorities, component distributors, radio registrations. Accounts held in a supplier’s name are difficult to recover.
• Consider escrow for critical products, where source and build materials are held by a third party and released on defined events. It costs a modest annual sum and is worth it where a product’s life is long.
• Ask who else understands it. A supplier where one engineer holds all the knowledge carries the same concentration risk as an internal team of one.

The second point is the one most often missed. Teams confirm they have the source, assume that is sufficient, and discover years later that the toolchain version, the specific library builds and a configuration step on someone’s machine were all needed to produce the binary that actually shipped. Building it yourself once, from a clean checkout, converts an assumption into a fact — and it is a reasonable thing to ask for as an acceptance step.

Ending well

Every engagement ends, whether at successful completion, because the product moves in-house, or because it is not working. Planning for that is not pessimism; it is what keeps the option open.

• Handover as a defined deliverable, with the list agreed at the start and a portion of payment attached to it.
• A transition period where the supplier remains available for questions at an agreed rate, even after formal completion.
• Accounts and credentials transferred, including repositories, cloud accounts, registrations and signing keys.
• Physical items returned: prototypes, fixtures, test equipment, remaining components.
• A documented state of play: what works, what is known not to work, what was deferred and what would be done next.

That last item is the most valuable and the least often requested. An honest account of a project’s loose ends is worth more to whoever picks it up than any polished summary, and a supplier willing to write one is demonstrating something about how they work.

A worked situation

A manufacturer of industrial equipment wants to add connectivity to an existing product line. They have mechanical and controls engineering in-house, no embedded software capability, and no experience of connected products.

The reasoning that tends to apply:

• The connectivity is not their differentiator — the machine is. That argues for external development, with the intention of keeping the machine knowledge internal.
• But it becomes ongoing. A connected product needs updates and security maintenance for years, as covered in security regulation. So the arrangement must produce something maintainable, whether by them or by an ongoing relationship deliberately chosen rather than defaulted into.
• A definition phase first. What the data is for, who consumes it, what the support commitment will be. Weeks, not months, and it changes the architecture.
• Handover specified from the start, including a reproducible build environment, because the alternative is being unable to issue a security update without the original supplier.
• An internal owner named, probably from the controls team, who can answer questions about the machine and accept the result.
• A small first piece of work — a feasibility study on one machine — before committing to the programme.
• Explicit agreement on tooling and test fixtures, because volume production will follow and they should not be locked to one manufacturer by a fixture they do not own.

Notable here is how little of this concerns choosing between suppliers on capability. The decisions that matter are about scope, ownership and maintainability, and they are made before any supplier is selected.

A short glossary

Terms used in this article

Term	Meaning
Background IP	What each party brought to the project. Normally stays with its owner; you need a licence to use it.
Foreground IP	What the project creates. The part contracts usually address.
Assignment	Transfer of ownership, as distinct from a licence to use. Timing matters.
Licence	Permission to use something someone else owns, on stated terms.
Definition phase	Short paid work producing a specification and a realistic estimate before the main project.
Acceptance criteria	What must be demonstrated for a milestone to be met. Written in advance or argued about later.
Statement of work	The document defining scope, deliverables and exclusions. The thing both sides point at.
Change control	The agreed mechanism for handling scope changes. Necessary because changes are certain.
Handover pack	Everything needed for someone else to continue the work.
Escrow	Holding source and build materials with a third party, released on defined events such as supplier failure.

If you take one thing away

Decide what you will receive at the end, and write it down before work starts. Not the product — the source files, the build environment, the fixtures, the documentation and the rationale.

Every other question in this article is downstream of that one. A project that delivers a working product you cannot modify, rebuild or move has delivered something with a shorter life than you paid for, and the moment to prevent that is at the beginning, when it costs a conversation.

When not to outsource

Against our own interest, and worth stating clearly:

• When it is your core differentiator and you intend to keep developing it. The knowledge accumulates wherever the work happens, and buying it back later is expensive.
• When requirements are genuinely unknown and will be discovered by building. That work is hard to specify and therefore hard to contract, and it suits people who can change direction daily.
• When nobody internally has capacity to engage. An external team generates questions, and unanswered questions become assumptions, and assumptions become rework.
• When the budget only covers the build. Integration, iteration and support follow, and a project funded only to first delivery tends to stop just before it becomes useful.
• When you are outsourcing because it seems cheaper. It sometimes is, and rate alone is a poor reason: communication overhead, specification effort and knowledge transfer are real costs that do not appear on a rate card.

Building the capability in-house afterwards

A common and sensible trajectory is to have a first product developed externally, then bring the work in-house for subsequent products. It succeeds or fails on whether it was planned from the start.

What makes it possible: documentation written for somebody who was not there rather than as a reminder for those who were; code and schematics organised for a newcomer; a period of overlap where your engineers work alongside the supplier rather than receiving a handover after they have gone; and the supplier knowing this is the plan, since a supplier expecting a long relationship will make different choices from one preparing you to leave.

That last point deserves candour. A supplier told at the outset that the intention is to internalise the work has an incentive problem, and the honest way to handle it is commercially — paying for knowledge transfer as a deliverable rather than expecting it as goodwill. A well-run transition is worth paying for, and treating it as a defined piece of work rather than an afterthought tends to produce a better result for everyone.

What makes it fail: assuming a working product implies transferable knowledge, hiring the internal team after the supplier has finished, and discovering that the reasons behind a hundred small decisions were never written down. The design rationale is the part that does not survive an unplanned handover, and it is the part that matters most when the second product is designed.

Handover, agreed at the start

The single most useful thing to settle before work begins is what you receive at the end, because at the end your leverage has gone.

• Source files, not exports. Native schematic and layout files, not just PDFs and Gerbers. Editable mechanical models.
• Firmware source with a build environment that reproducibly produces the shipped binary. Ideally containerised, as argued in embedded firmware practice.
• The bill of materials with approved alternatives and the reasoning behind critical choices.
• Test procedures and fixture designs, not just the physical fixture.
• The documentation pack a manufacturer needs, as set out in prototype to volume production.
• Design rationale for anything unusual — the decisions whose reasons are invisible in the files.
• Credentials and accounts: signing keys, cloud accounts, repositories, registrations made on your behalf.
• A defined support period and what it covers.

A supplier comfortable with that list is one worth working with. Reluctance is worth understanding before committing rather than after.

How we help with this

We do hardware, firmware and integration engineering, and we hand over the work product and its documentation so that you or another supplier can continue without us. We would want a paid definition phase before quoting anything substantial, because a price for work nobody has specified is a guess dressed as a number.

We do not take on explosive-atmosphere or life-safety work, we do not issue certifications, and we would say so in the first conversation rather than partway through. If the honest answer is that the work belongs in-house, or that a platform product would serve you better than a bespoke development, we would rather say that than take the project.

Related reading: idea to working prototype, prototype to volume production, industrial product development, and product cost reduction. For the wider picture, what industrial IoT actually is.

Questions we are asked about this

Common questions

What clients ask before starting

Who owns the IP if the contract does not say?

It depends on jurisdiction and on the nature of the work, and the default is frequently not what the paying party assumes. In several legal systems a contractor retains ownership of what they create unless the contract assigns it, with the customer receiving only an implied licence. This is precisely why it should be written down rather than reasoned about afterwards, and why we are describing the shape of the problem rather than giving legal advice.

Why do quotations for the same project vary so much?

Usually because the suppliers are quoting different scopes, not different prices. One may assume a single design pass and no certification support; another may include design for manufacture, pre-compliance and documentation. Before comparing numbers, compare what each includes, how many design iterations are assumed, what happens when requirements change and what is delivered at the end. A quotation that is half the others is normally missing something rather than cheaper.

Is fixed price better than time and materials?

Neither is better; they allocate risk differently. Fixed price suits well-defined work and makes the supplier bear estimation risk, which they price for and which makes them resistant to change. Time and materials suits exploratory work and leaves you carrying the risk. A common sensible arrangement is a fixed-price definition phase producing a specification, then a fixed price for the work that phase defined.

What should be delivered at the end of a project?

Everything needed for a different competent engineer to continue: source files rather than exports, firmware source with a build environment that reproduces the shipped binary, the bill of materials with alternatives, test procedures and fixture designs, and the rationale for anything unusual. A working product without these is a product you cannot modify, and it is worth agreeing the handover list before work starts rather than at the end.

How do we judge technical capability before committing?

Ask about a project that went wrong and what they did about it — the answer is more informative than any case study. Ask to speak to an engineer rather than a salesperson, and ask what they would not take on. A supplier with no stated limits has either not thought about them or is not being straight, and the limits are where the surprises come from.

Does distributed or offshore development work?

It can, and the deciding factors are rarely technical. What matters is overlap in working hours for the conversations that need to be conversations, written communication good enough that decisions survive the gap, and clarity about who can make a call without waiting. Where hardware is involved, the practical question is who physically has the boards, because remote debugging of a physical problem is slow and expensive.

When should we not outsource?

When the work is the core of your business and you intend to keep developing it, because the knowledge leaves with the supplier. When requirements are genuinely unknown and will be discovered by building, since that is difficult to contract for. And when nobody internally has the capacity to make decisions — an external team always needs someone on your side who can answer questions and accept the result.

What do you actually provide?

Hardware, firmware and integration engineering, with the work product and its documentation handed over so you are not dependent on us afterwards. We would want a definition phase before quoting anything substantial, because a price for work nobody has specified is a guess. We do not take on explosive-atmosphere or life-safety work, and we would say so at the first conversation rather than partway through.

Start a conversation

What are you trying to build, and what is undecided?

Tell us what the product is, what is already settled and what is not. If the honest answer is that you need something other than an external team, we would rather say so early.

Leave empty

Your name *

Email address *

Company

Country *

What are you working on? * I agree that iTechGeeks may use these details to respond to my enquiry. Privacy policy. Send enquiry ↗

Prefer email? Write to info@itechgeeks.in