I've set up an Acumatica development environment from a blank machine more times than I can count — for myself on a new laptop, for contractors joining a project, for a client's internal developer who'd only ever touched a SaaS instance through the browser before. The steps are documented officially, but the ordering and the gotchas that actually cost time are not, so here's the sequence I follow, with the parts that trip people up called out.
Get a local instance running before you touch Visual Studio
Resist installing Visual Studio first. Get a working local Acumatica instance running first, because half of "development setup" problems are actually instance problems disguised as tooling problems. Download the Acumatica ERP installer matching the version your client project targets — version alignment matters enormously here; developing a customization against 2024 R2 locally while the target instance runs 2023 R2 produces subtle API mismatches that waste hours. The installer handles IIS configuration, application pool setup, and database creation against a local SQL Server (Express is fine for development).
Once the instance is up and you can log into the browser UI with the default admin credentials, you have confirmed the web tier, app pool, and database are correctly wired — which is the actual hard part. Everything downstream assumes this works.
Visual Studio, the Acumatica SDK, and project structure
Install Visual Studio (the Community edition is fully sufficient for Acumatica development) with the ASP.NET workload. Then install the Acumatica-provided project templates and reference assemblies — these ship with the SDK download matching your instance version, not as a NuGet package pulling latest, which is a common point of confusion for developers used to floating package versions.
The project structure I use on every client engagement is a solution containing one class library per customization project, referencing the Acumatica assemblies from the local instance's bin folder (not a copy — reference the actual instance you're developing against, so you're never fighting a version drift between your compiled DLL and the running server):
ClientName.sln
ClientName.TaxExtensions/ (class library, references instance assemblies)
ClientName.ApprovalWorkflow/ (separate library — separate customization project)
ClientName.Tests/ (unit tests against graph logic, where feasible)
Keep the C# in these libraries, not typed directly into the Code Editor inside a customization project in the browser. You get IntelliSense, source control, and the ability to actually debug — which the in-browser editor cannot give you.
To hit a breakpoint, you attach the Visual Studio debugger to the IIS worker process (w3wp.exe) hosting your local instance, and your compiled DLL must actually be the one loaded there — via the customization project's publish, or by copying the build output into the instance's bin path for rapid iteration during active debugging. Attaching to the wrong worker process (common on a machine running multiple sites) produces a debugger that "never hits" a breakpoint you know is correct, and costs new developers a confused afternoon almost every time.
The publish loop you'll run constantly
The realistic inner loop is: edit code in Visual Studio, build, publish the customization project (either via the SDK's publish tooling or by packaging and uploading through Customization Projects in the browser), then test in the browser. For faster iteration during active debugging, some developers copy the built DLL directly into the instance's bin folder and recycle the app pool rather than doing a full customization publish each time — faster, but remember to do a proper publish before committing, since a bin-copied DLL is not tracked by the customization project's package.
Source control from day one, and matching dev/staging/prod versions
Put the solution in git immediately, even for a solo proof of concept — customizations that live only inside a customization project's internal storage are one bad publish away from being unrecoverable. On any real engagement I maintain at least three environments: local dev (fast iteration, disposable), a staging tenant matching production's Acumatica version exactly (for realistic testing and client UAT), and production. The version-matching between staging and production is not optional — publishing a customization built against a newer SDK than production runs is one of the most common self-inflicted outages I've seen on client projects.
What actually takes the first week, honestly
Installer and Visual Studio setup is a few hours if versions line up cleanly. What actually eats the first week is learning the instance's data: importing or generating realistic sample data, understanding which customizations are already live on the client's real instance so you don't duplicate work, and getting a debugging rhythm down. Budget for that explicitly when a new developer joins a project — "environment setup" as a line item should include time to get comfortable, not just time to get the installer to complete.
Wrapping up
Get a local instance running and confirmed working before installing anything else, match SDK and instance versions religiously, keep customization code in a real Visual Studio solution under source control rather than the browser's code editor, and understand the debugger attach story before you need it under deadline pressure. The mechanical steps are well documented; the ordering and the version-matching discipline are what actually save a new developer's first week.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.