// AUDIO ENGINEERING SERVICES
Hire Expert JUCE & C++ Developers
Hiring a JUCE developer means adding a senior C++ audio engineer to your team for a defined scope. We work inside your repository and your review process on VST3, AU, AAX, and AUv3 plugins, real-time DSP, and release engineering. A developer usually starts within one to two weeks.
Host Behaviour in VST3, AU, AAX
We know how auval gates an AU before Logic Pro will load it, how Pro Tools hosts AAX out of process, and how Cubase recalls VST3 parameters between sessions. That knowledge costs a generalist weeks.
JUCE UI Implementation
We work from your designer's Figma or PSD and build the editor: resizable layout, correct DPI and Retina scaling, and repaint work that stays clear of the audio callback.
Real-Time DSP Engineering
Lock-free programming, SIMD where profiling justifies it, denormal handling, and filter design. Code that passes pluginval and sanitizer builds before it reaches your reviewers.
Architecture & Migration
Parameter and state design that survives version upgrades, Projucer to CMake migrations, and JUCE upgrades planned so an OS release never blocks your own.
Code Review and Mentoring
We review your team's pull requests for real-time safety and host behaviour and explain the reasoning, so the knowledge stays with your developers after the engagement ends.
Release Engineering
CI across macOS and Windows, pluginval in the pipeline, code signing, macOS notarization, and installers, so shipping stops depending on one engineer's laptop.
// THE TECHNICAL GAP
Why is it so hard to hire an audio C++ developer?
The hiring pool is small and slow
Audio C++ roles stay open for months. The overlap between modern C++, real-time constraints, DSP mathematics, and the actual behaviour of Logic Pro, Cubase, Pro Tools, Ableton Live, Reaper, and FL Studio describes a small group of engineers, and most of them already have jobs. Posting the role and waiting costs you a release window.
A strong generalist still needs months
A good C++ engineer can learn JUCE. What takes longer is knowing that an allocation in processBlock turns into field crash reports, that VST3 parameter IDs have to stay stable forever, or that auval will reject an AU before Logic Pro ever loads it. That learning happens in your product, in front of your users.
How we drop in
We work in your repository, your branching model, and your sprint cadence, and we review inside your pull requests. Onboarding starts with a defined first task instead of a reading week, so the first merged pull request normally lands in the first week.
// THE TEAM
Which engineers work on your project?
Named engineers, not a bench
Gustavo Castelo, Principal Engineer and founder, leads architecture and DSP work. Aaron Petrini and Carlos Garín are audio software developers who carry plugin and application work day to day. You know which of them is assigned before you sign anything, and we do not subcontract to developers you have not met.
Three ways to engage
A short-term project with a defined scope, ongoing augmentation where a developer sits inside your sprints, or hourly consulting for architecture reviews and scaling questions. Rescue work on CPU spikes and crashes usually starts as a performance consultation, with a written report, before anyone commits to a longer engagement.
Time zones and availability
We work from Europe on CET with teams in North America and Asia, and agree overlap hours during onboarding. A developer typically starts within one to two weeks of agreeing terms.
// HOW IT WORKS
From Availability Call to Handover
Each stage produces something written or merged, so progress is visible to your team and to your board.
Availability call and brief
A call about the work and your team, then a short written engagement brief: who is assigned, start date, rate, overlap hours, and how we report. NDA signed first if you prefer.
Onboarding deliverable
We build your project on day one and agree a first task that ends in a merged pull request. If the repository does not build on a clean machine, fixing that is the first deliverable.
Embedded work
Your tooling, your branch model, your reviews. We join the standups that are useful and raise pull requests small enough for your team to review properly.
Weekly written report
Merged work, what is in review, what is blocked, and what we consider risky. Written so a founder and a lead developer can both act on it.
Handover
At the end of an engagement you receive a handover document, a build verified on a clean machine, and the reasoning behind the structural decisions we made.
// WHAT GOES WRONG
Pitfalls in Audio Team Augmentation
A Build Only One Machine Can Do
Onboarding stalls on undocumented SDKs, a pinned Xcode version, or a missing JUCE module. We get the project building on a clean machine and write the steps down as the first task.
Real-Time Regressions in Review
Pull requests add allocations, locks, or logging inside processBlock because nothing in CI forbids it. We review for that and add the checks that catch it next time.
Host Bugs Nobody Reproduces
A crash that only happens in Pro Tools, only on project reload. Without the host installed and a written reproduction, those tickets sit open for months. We keep the hosts and test in them.
Signing Knowledge in One Head
When one person holds the certificates and the notarization steps, a holiday becomes a release blocker. Signing and installer steps belong in CI with the procedure documented.
Deferred JUCE Upgrades
Skipping JUCE versions until a macOS release forces the issue turns a two-day upgrade into a month of breakage. We plan framework upgrades against your release calendar.
Scope With No Edges
Augmentation drifts until the outside developer owns everything and nobody can say who is accountable. The engagement brief states what we are responsible for and what stays with your team.
// SHIPPED WORK
Work Done Inside Client Products
CLIENT: AUDIOMODERN
Playbeat 4
End-to-end development of the full application and the sequence randomization engine in JUCE and C++. Performance and stability improved across complex sessions, CPU spikes dropped, and crashes in high-load scenarios were eliminated.
CLIENT: DISCODSP
OB-Xd, Discovery Pro, Corona
UI and UX implementation and maintenance across the DiscoDSP plugin line, with interface rewrites for three shipping instruments. Better visual feedback, smoother interactions, and a renewed lifespan for the plugins.
CLIENT: LATENCYFIX
LatencyFix
End-to-end development including Ableton Remote Scripts, Pro Tools PTSL automation, and product UI implementation, producing a remote recording workflow that keeps DAW sessions aligned for distributed collaboration.
// FIT
When is hiring us the wrong call?
We are not a staffing agency and we do not place junior developers. If you need an employee on your payroll, someone in your office, or five engineers inside a month, another supplier fits better. A three-person senior team takes on a small number of engagements at a time, so we will tell you when the next slot opens rather than promise one that does not exist.
// FAQ
Common Questions
How quickly can a developer start?
Typically within 1–2 weeks after we scope the engagement and agree on terms. For urgent situations we can often move faster.
What engagement models do you offer?
Short-term project work, ongoing team augmentation, and hourly consulting. We adapt to what works for your team and timeline.
How does this differ from hiring via a freelancer platform?
We are senior engineers with a proven audio track record, not generalists. You get someone who already knows JUCE and audio deeply, with zero ramp-up time on fundamentals.
What time zones do you cover?
We are based in Europe (CET) but regularly collaborate with teams in North America and Asia. Overlap hours are agreed during onboarding.
Do you sign NDAs?
Yes. Confidentiality and white-label arrangements are standard practice. Your codebase and product details remain yours.
Who exactly will work on our codebase?
You know the name before signing. Engagements are staffed by Gustavo Castelo, Aaron Petrini, or Carlos Garín, and we tell you which one and why that match suits the work. We do not subcontract to developers you have not met.
Can a developer work in our repository and review our pull requests?
Yes. We work inside your repository, your branching model, and your review process. Reviewing your team's audio code is often the most useful part of an engagement, because the knowledge stays with your developers afterwards.
// RELATED SERVICES