top of page
Adiuvo Engineering & Training logo
MicroZed Chronicles icon

MicroZed Chronicles: So You Want to Run Your Own Engineering Company

Recently, I’ve noticed a lot of questions on social media and Reddit/FPGA about setting up your own engineering company. Having run one for about 15 years now, I thought I’d hold a webinar on running your own business. The webinar was one of the most enjoyable I’ve done in a while. You can see the full webinar here, but I thought it might be a good idea to share some key takeaways from the session in this blog.


ree

Being highly technical and competent on its own is not enough. Of course, it helps because when you’re running your own engineering company, the buck really does stop with you, and you need to get things working because that’s how you get paid. However, you also need experience across several projects, ideally in different functional areas, to understand various engineering governance and delivery lifecycles. You also need to know how to manage customers and projects, especially when things don’t go as intended. I’ve learned the most in my engineering career from projects that didn’t run smoothly. In short, you need to round out your skills beyond FPGA design, particularly in team management, customer communication, project leadership, and delivery management.


Cash flow is critical. Outside of contracting on an hourly basis (which isn’t really running a company), clients are most likely to engage on a fixed-price model. That means you’re paid when you achieve milestones, perhaps for agreeing on requirements, completing the RTL, finishing verification, or delivering the bitstream. These milestones can shift, as projects inevitably experience change. Ensure you have sufficient cash coming in to handle these fluctuations. Another lesson I learned, after a company I worked with went into Chapter 11, is to never work cash-negative. Always ensure your milestones cover your project outgoings.


Clearly define your mission and goals. Early on, we defined our mission, goals, and strategy. Doing this helped us decide where to focus our engineering services and what products, if any, we wanted to develop. Like good engineering practice, writing these down gave us focus and a framework to review periodically to ensure we’re staying true to our strategy. Although, I’ll admit, the strategy didn’t say “start an FPGA conference and journal.”


Tools matter. Determine what tools you need, such as editors, simulators, and vendor licenses. There are excellent open-source tools that can support design creation, such as FuseSoC, TerosHDL in VS Code, and WaveDrom for documenting timing waveforms and register bit fields. However, clients will expect programming files and deliverables created with professional toolchains, especially for safety- or security-critical projects. My tooling policy is to purchase perpetual licenses to ensure the capability always exists. I also budget carefully so we can invest in tools incrementally, as you’ll also need lab equipment including JTAG programmers, test tools, oscilloscopes, logic analyzers, power supplies, power monitors, probes, and cables. It’s amazing how much you need once you get started.


Codify how work gets done. It doesn’t have to be War and Peace, but you need an engineering governance flow that defines how you progress from initial customer contact to final bitstream delivery. Over the years, we’ve developed a simple development process that outlines how we perform our FPGA engineering. Supporting that process, we have several guides, such as RTL coding standards, IP creation guidelines, and verification best practices. The goal is to not only understand how work gets done but also to develop solutions and components that can be reused across projects, making us more agile and efficient.


I know I said five points, but there are two more important aspects:

  • Clearly define what project completion looks like. This ensures both parties know when the project is finished and when your final invoice can be submitted.

  • Collect statistics on your developments. This data allows you to make more accurate proposals in the future.

If you’re thinking of taking the leap, I encourage you to watch the full video. Honestly, it’s the best thing I’ve ever done, though I’m now completely unemployable in the corporate world.


FPGA Conference

FPGA Horizons US East - April 28th, 29th 2026 - THE FPGA Conference, find out more here.


FPGA Journal

Read about cutting edge FPGA developments, in the FPGA Horizons Journal or contribute an article.


Workshops and Webinars:

If you enjoyed the blog why not take a look at the free webinars, workshops and training courses we have created over the years. Highlights include:



Boards

Get an Adiuvo development board:

  • Adiuvo Embedded System Development board - Embedded System Development Board

  • Adiuvo Embedded System Tile - Low Risk way to add a FPGA to your design.

  • SpaceWire CODEC - SpaceWire CODEC, digital download, AXIS Interfaces

  • SpaceWire RMAP Initiator - SpaceWire RMAP Initiator,  digital download, AXIS & AXI4 Interfaces

  • SpaceWire RMAP Target - SpaceWire Target, digital download, AXI4 and AXIS Interfaces

  • Other Adiuvo Boards & Projects.


Embedded System Book   

Do you want to know more about designing embedded systems from scratch? Check out our book on creating embedded systems. This book will walk you through all the stages of requirements, architecture, component selection, schematics, layout, and FPGA / software design. We designed and manufactured the board at the heart of the book! The schematics and layout are available in Altium here.  Learn more about the board (see previous blogs on Bring up, DDR validation, USB, Sensors) and view the schematics here.


Sponsored by AMD

bottom of page