I'm trying to start taking on smaller contract jobs for digital logic design. I've built a few proofs of concept for signal processing, but I really struggle with the business side of things. When a small startup comes to me needing a custom filter implemented in an FPGA, how am I supposed to figure out a fair rate? Do you quote by hours, or do you base it on the complexity of the required Verilog code? If the scope changes mid-project, which is almost guaranteed, how do I structure the initial contract so I don't end up doing work for free? I'm worried about underselling myself but also don't want to charge like a massive corporation for a few hundred lines of code. Any advice on pricing methodologies would be helpful.
How do I price a small custom FPGA project?
Oct 30, 2026
Last reply: 10 hours ago
4 Replies
First reply
Most of the time, basing the rate purely on estimated hours is the least protected way to work, even if it seems more fair initially. Custom digital design is highly variable because the architecture changes everything. A safer approach is to quote based on defined milestones.…
Read the full replyMost of the time, basing the rate purely on estimated hours is the least protected way to work, even if it seems more fair initially. Custom digital design is highly variable because the architecture changes everything. A safer approach is to quote based on defined milestones. You break the project into phases—like requirements specification, HDL coding, simulation, and final implementation—and assign a fixed fee to each phase. This forces the client to agree to specific deliverables before you move on. When it comes to the actual complexity of the Verilog code, that should determine the value, not just the lines of code. If a client comes to you with a complete, highly optimized specification, your job is mostly implementation, and you can quote that small job accordingly. But if they are vague, you charge a higher rate for the initial architectural design and refinement phase, because that is where the risk and intellectual effort are highest. Don't underprice your expertise just because the code might only be a few hundred lines. Scope creep is the biggest killer of freelance projects. To prevent this, your initial contract needs a very clear statement of work. Define what is IN scope and what is OUT of scope. Whatever the client asks for that falls outside those agreed-upon boundaries is a 'Change Order.' The contract must explicitly state that any Change Order requires a written amendment and a mutually agreed upon price increase or time extension. It sounds bureaucratic, but it protects you from endless revisions. Regarding networking, don't just wait for job postings. Build relationships with the local electrical engineering firms or product development houses that frequently require specialized hardware integration. These smaller companies often need specialized skills but lack the internal capacity to hire full time. A simple introduction to the right lead engineer can lead to solid, ongoing work without you needing to post anything anywhere.
I think the push for milestone-based fees is overkill for early projects. Quoting fixed fees for steps like 'HDL coding' or 'simulation' actually gives me too little flexibility if the client changes thier mind about the underlying logic midway through. You promise to finish a phase, but if the concept itself proves mathematically impossible, you're stuck. Hourly rates, if tracked closely, allow for that reality.
I found that starting with a small block of time for the initial architectural review lets you discover if the client's request is even feasible before committing to any phase fee. That way, you don't waste effort designing something that ends up being a waste of everyone's money.
I find the point regarding thorough definition of project phases quite valid, altough it seems vital to also meticulously define the technical constraints during that initial scoping period. If a client presents a vague requirement for a 'signal processor' without specifying the required clock frequency or the necessery data bit-width, the architectural design phase becomes nearly impossible to estimate with any degree of accuracy. The inherent uncertainty in those fundamental parameters is what drives the true value of the early consulting work. If we agree on those numbers, the estimation process becomes substantially more predictable.
Update: took the milestone idea for a spin on a small job and it went okay, but I ran into the scoping problem the last reply mentioned. The client literally could not give me a target clock rate or resource budget, they just said make it fast. How do you quote milestones when the customer can't answer basic constraint questions yet?
Join the Discussion
Have something to add? Share your thoughts — no account required.
Didn't find your answer?
Ask the community — no account required