solidSF vs Onshape

Where Onshape leaves you exposed

Your work is public unless you opt out. By default, every document you create in Onshape is published to a public repository where any other Onshape user can open, copy, and fork it. That is workable for a hobby part. It is the wrong default for a startup designing a product, a contractor under NDA, or a student protecting a thesis project. solidSF inverts it: every document on every workspace is private by default.

Onshape does not own its kernel. Onshape's geometry runs on Siemens Parasolid, a third-party kernel it licenses. That bounds what Onshape can do at the geometry layer to what Siemens exposes, and it is why Onshape's automation surface stays shallow. solidSF wrote its own Rust B-rep kernel — exact geometry with six surface and six curve types, a boolean engine with exact-first recovery, and a full feature tree with rollback — and keeps it protected on the server. Bryan drives that kernel through typed server APIs.

The AI advises; it does not act. Onshape's assistant answers questions about the product. It does not build the feature tree for you. Bryan calls the same 55 typed CAD tools a human uses: creating sketches, extruding bodies, cutting holes, adding fillets and patterns, building drawing views, and preparing CAM setups before handing back an editable model.

Whole categories of work simply are not there. Onshape has no text-to-part generation, no SDF/lattice generative modeling, and no in-browser fluid simulation. Those are core suites in solidSF, described below.

What solidSF actually is

Here is the product, feature by feature. Every capability below is available from the browser workspace and reachable through Bryan, while geometry stays on the server.

The through-line is Bryan. Because solidSF owns and hosts the kernel, Bryan operates real server-side geometry through typed tools rather than narrating from the outside. An advisor bolted onto a licensed kernel cannot build a part, grow a lattice, or stand up a drawing for you.

Feature comparison

Migrating from Onshape

You do not need a perfect history transfer to move. You need geometry, drawings, and a path to keep building.

1. Export from Onshape. Export parts and assemblies to STEP AP214 (it preserves more annotation data than AP203). Export drawings to PDF and DXF.
2. Open a solidSF workspace. Create an organization and a project. Privacy is on by default.
3. Drag the STEP files in. solidSF heals on import — sliver faces, tolerance mismatches, topology — and lands editable bodies in the feature tree.
4. Re-author the driver features. Most parts have five to twenty load-bearing features. Re-author those in solidSF, or ask Bryan to build them from a description.
5. Bring drawings and PDM across. Recreate drawing templates from the exported PDFs, then map your release states into solidSF revisions and locks.

When Onshape is still the right call

Onshape is an excellent product and there are situations where it wins today. If your team has standardized hundreds of engineers on Onshape branching and merging, has customized its enterprise release management, has direct PLM bridges to Siemens Teamcenter or Dassault Enovia, or has a contractor network already locked into Onshape enterprise permissions, the switching effort is real. A deep Onshape Enterprise footprint is infrastructure, and moving it is a deliberate transition, not a single decision. solidSF is the move for teams that want to switch on the engineering side too — private work, a protected server-side kernel Bryan can drive, and suites Onshape does not ship.

FAQ

See it for yourself

The fastest way to decide is to watch the server-side kernel and Bryan work. Open a part, ask Bryan to add a feature, and run a drawing view.