Acumatica gives you two genuinely different ways to modify a screen's C# behavior — the customization project's in-browser Code Editor, and a real Visual Studio project referencing the instance's assemblies — and I still meet developers who default to the browser editor for everything, including work that would go faster and safer in Visual Studio. Here's the honest comparison, including the cases where the browser editor is actually the right call.
Two different development experiences, same underlying customization mechanism
The in-browser Code Editor, accessible from within a Customization Project record, lets you write C# directly against the live instance, compile it in place, and see results without leaving the browser. There's no separate project file, no local build — the code lives inside the customization project's own storage.
A Visual Studio solution referencing the instance's assemblies is an ordinary class library project, built locally, with the compiled DLL packaged into a customization project (or bin-deployed directly during active debugging) rather than the source living inside the project's browser-editable storage.
Both ultimately produce the same kind of artifact — compiled code extending a DAC or graph — deployed through the same customization project mechanism. The difference is entirely in the development experience around getting there.
Where they genuinely differ
| Aspect | Browser Code Editor | Visual Studio |
|---|---|---|
| IntelliSense / autocomplete | Minimal to none | Full, against actual instance assemblies |
| Debugging (breakpoints, step-through) | Not possible | Full debugger, attach to w3wp.exe |
| Source control | None natively — code lives in the project's internal storage | Git, same as any other codebase |
| Unit testing | Not feasible | Standard .NET test frameworks work |
| Setup cost | Zero — open the browser and type | Real — SDK, matching version assemblies, project wiring |
| Refactoring tools (rename, find usages) | None | Full IDE tooling |
| Good for quick one-off scripts / diagnostics | Yes, genuinely convenient | Overkill for a five-line diagnostic snippet |
When I still reach for the browser editor
It's not purely a legacy or beginner tool — there are real cases where it's the faster, correct choice: quick diagnostic one-offs on a client's instance (a short script to check data state, not something that will ship as a permanent customization), rapid prototyping to confirm an approach works before investing in a proper Visual Studio project for the real implementation, and emergencies where a client needs an urgent small fix and setting up a full local environment against their exact instance version would cost more time than the fix itself. The common thread: small, throwaway, or genuinely urgent — never for anything that will live in production long-term.
Code living only inside a customization project's internal storage has none of source control's protections — no history, no branches, no backup beyond whatever export/backup discipline you separately maintain. I've seen real customization work lost because a customization project got deleted or corrupted and nobody had exported the project as a package recently. Any code written in the browser editor that's going to matter beyond the next hour should be exported and committed to source control promptly, or better, moved into a proper Visual Studio project the moment it's clear it's not throwaway.
For anything shipping to a client, Visual Studio is not optional
For real, ongoing customization work — the kind that will be maintained, extended, and upgraded across future Acumatica versions — a Visual Studio solution under source control is not a nice-to-have, it's the baseline professional standard, for reasons beyond just convenience: code review is only possible against a diff in a real repository; a second developer picking up the work needs git history and IntelliSense to be productive quickly; and debugging a production issue without breakpoints, working entirely from log statements and guesswork, is a genuinely worse and slower experience than most developers who've only used the browser editor realize until they've done both.
The hybrid workflow that actually works well
My real day-to-day pattern: prototype fast in the browser editor when I'm still figuring out the right approach to a problem, confirm it works, then immediately port the confirmed approach into the Visual Studio solution as the real, source-controlled implementation, and delete the throwaway browser-editor version. The browser editor is a scratchpad for exploration; the Visual Studio project is where anything that matters actually lives. Treating the two as interchangeable, rather than as different stages of the same workflow, is where I see developers get into trouble — either wasting Visual Studio setup time on a five-minute diagnostic, or shipping unreviewable, unversioned browser-editor code as a permanent client customization.
Wrapping up
The browser Code Editor and a Visual Studio solution aren't competing tools so much as different stages of the same workflow — the browser editor for fast, disposable exploration and genuine emergencies, Visual Studio for anything that will be maintained, reviewed, debugged properly, or shipped to production. The mistake to avoid isn't using the browser editor; it's forgetting to graduate real work out of it before it becomes an unversioned, undebuggable liability sitting inside a customization project's internal storage.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.