solidSF vs SolidWorks

The wedge: SolidWorks files, no Windows install, $29/mo

SolidWorks remains the file format that mechanical engineering runs on. If you have a job, a part, a supplier, or a contract, there is a good chance a .sldprt, .sldasm, or .slddrw is involved somewhere. Dropping SolidWorks the application is hard precisely because the files have inertia. Other "alternatives" force you to convert through neutral formats and lose your parametric history, then re-author every feature in the new tool.

solidSF takes a different approach. The Rust kernel includes a native SolidWorks feature-tree replay that opens .sldprt files directly. It walks the feature history, replays the sketches and operations against the solidSF kernel, and produces a live parametric part inside the workspace. Edges and faces have stable IDs, downstream features hold their references, and the part is editable on day one. This is meaningfully different from a STEP import, which is a static body without history.

The second piece of the wedge is the platform surface. SolidWorks is Windows-only. Teams that have moved their development to Mac, that have engineers working on Linux because the rest of their stack is on Linux, that want a contractor to open a part on their iPad while standing next to a machine, or that just got a new employee with an Apple Silicon laptop are all forced into Parallels, Boot Camp, virtualization desktops, or a "the CAD person has a Windows tower" hack. solidSF runs in a browser. The friction collapses.

The third piece is price. SolidWorks Design Standard, Design Professional, and Design Premium are published at roughly $2,820, $3,720, and $4,716 per user per year respectively, depending on reseller and region, and that excludes 3DEXPERIENCE Works PDM, simulation packages, and required annual maintenance. solidSF Pro is $29 per user per month — $348 per year. The gap is roughly an order of magnitude before any add-ons.

Real feature-tree migration

"Migration" is a word other CAD vendors use loosely. In practice, most "SolidWorks migration" pipelines convert through STEP and produce a non-parametric solid body. You can rotate it. You can mate it into an assembly. You cannot easily edit the boss extrude that defined its primary thickness.

solidSF reads the SolidWorks feature tree itself. The kernel walks the part's operation history, identifies each feature type — extrude, revolve, sweep, loft, fillet, chamfer, hole wizard, sheet metal, pattern, mirror, shell, draft, rib, and so on — and replays those operations against solidSF's native operation set. The result is a parametric solidSF part that has the same modeling intent as the original SolidWorks file. You can change a sketch dimension and the part regenerates. You can suppress a feature and downstream features adapt. You can rename a feature and edit it in plain English.

Coverage today spans the typical feature set used in mechanical part modeling. Heavily customized SolidWorks parts using deep macros, third-party add-in geometry, or proprietary library features may fall back to a healed STEP import for the affected sections, with the rest of the tree intact. We are honest about this gap. The roadmap covers expanded macro and add-in coverage.

Assemblies and drawings are also on the import path. Assembly mates come across into solidSF assemblies. Drawings come across into the solidSF drawings module where they can be regenerated against the migrated parts.

Mac, Linux, iPad — your team works where they work

The "you must use Windows" requirement for SolidWorks has been a tax on hardware teams for decades. Engineers want to work on Mac. Founders want to open a part on their iPad. Contractors want to model on Linux because the rest of their stack is on Linux. Universities increasingly issue ChromeOS or Apple Silicon laptops. Every one of those situations has historically resolved as "go buy a Windows machine and run SolidWorks on it."

solidSF runs in a browser on every one of those platforms with no modification. WebGPU handles the GPU surface, WebAssembly hosts the Rust kernel, and there is no installer. macOS, Linux, Windows, ChromeOS, and iPad are all first-class. Sign in, open a workspace, and the same product runs against the same files for every engineer on the team. This is what makes solidSF function as "SolidWorks online" rather than "SolidWorks with extra steps".

The collaborative consequence is real. A founder can open a part from their iPad in a vendor's shop. A consultant can sign in on a borrowed laptop. A student can use the same product on their personal Mac that an enterprise engineer uses on their Windows tower. The workforce surface widens dramatically.

Feature comparison

Migration from SolidWorks

The migration path is deliberate. The point of feature-tree replay is to keep the cost low enough that you do not have to commit a full quarter to switching.

1. Choose a pilot project. Pick one active project that is small enough to move in a day. Not a 5,000-part assembly. A representative project with ten to fifty parts and a few drawings.
2. Sign in to solidSF. Create an organization at solidsf.com. Set up your team, roles, and a project. Privacy is on by default.
3. Drag in your SolidWorks files. Drop the .sldprt, .sldasm, and .slddrw files directly into the workspace. solidSF replays the feature tree per part, brings across assembly mates, and surfaces the drawings into the drawings module.
4. Review and edit one part. Pick a representative part and walk its feature tree in solidSF. Make a sketch edit. Confirm downstream features regenerate. Add a fillet. Run a drawing view.
5. Set up PDM. Map your existing SolidWorks PDM revisions and release states into solidSF revisions and locks. Add your team, set permissions, do a check-in/check-out test on a non-critical part.
6. Run CAM if needed. Recreate the CAM setup for one part in solidSF. Post to GRBL, Haas, or Fanuc. Compare against your reference G-code. If you use a different controller, contact us and we will validate the post.
7. Onboard one engineer. Have a single engineer use solidSF as their primary tool for two weeks on the pilot project. Keep SolidWorks alive for legacy and parallel work.
8. Expand by project, not by mandate. Once the pilot engineer is comfortable, route the next new project through solidSF. Existing SolidWorks projects can run to completion in parallel. Seats can retire as projects close.

When SolidWorks is still the right call

SolidWorks has spent three decades building a deep ecosystem. If your team has built workflow around a large library of custom SolidWorks add-ins — proprietary tube-routing extensions, electrical-harness tools, specialized molding-design plugins, integrated Simulia or Abaqus interfaces, or industry-specific add-ins from third-party vendors — those add-ins may not have a direct solidSF equivalent today. If your company has a 100-engineer footprint already locked into SolidWorks PDM Pro with twenty years of part libraries, established vault workflows, and engineering change management processes that map specifically to SolidWorks data cards, the switching cost is genuine. If your supply chain mandates SolidWorks deliverables in a specific revision and your customer audits your engineering process against SolidWorks templates, again, the right answer in the short term is to keep SolidWorks for those touchpoints. The honest read is that solidSF is the right move for new teams, new projects, hardware startups, contractors who need to deliver on multiple platforms, and established teams that are tired of paying the Windows-only tax — but a deep, deeply customized, regulated SolidWorks installation should be migrated deliberately, project by project, rather than ripped out overnight.

FAQ

Open the workspace

The shortest path to a real evaluation: sign in, drop one .sldprt file into solidSF, and edit it. The feature tree replay is the wedge — try it on a real part.