On 15 October 2026, Tesla unveiled a new version of its Roadster sports car at a SpaceX test site in Texas. In the livestreamed demo the car drove up a curved ramp, left it using cold-gas thrusters, flipped in the air and landed on its wheels. Tesla says certain versions reach 0 to 60 mph in about a second. Production is planned for 2028, and no price was announced.

We are a software company, not a car company, and we have no connection to Tesla. We are not going to judge the car. But the reveal is a clear example of something every business that buys or builds software runs into: the gap between a demo and a product people can rely on every day.

What was actually announced

Tesla and Elon Musk made the claims, and independent outlets reported them. Here is what the coverage says:

  • The car was shown at an event near Waco, Texas, on 15 October 2026.
  • Tesla says certain versions accelerate from 0 to 60 mph in about one second and have a top speed above 230 mph. Reports describe these as company figures, not independently tested numbers.
  • Production is planned to start in 2028. No price was given. Tesla's website takes reservation payments, which are deposits and not sticker prices.
  • Tesla first showed the Roadster in 2017 and said then that deliveries would start in 2020.
  • CBS News reported that regulators have no clear answer on which agency would oversee a car that flies, and that the FAA said the vehicle does not meet its definition of an aircraft.

Treat all of this as claims until the car is built and tested by others. That is the point of this post.

Lesson 1: a demo shows what is possible, not what is dependable

A demo is built to work once, in front of an audience, under the best conditions. Software demos are the same. A vendor can show you a smooth sales invoice and a tidy report in ten minutes. What you need to know is different: what happens when the internet drops, when two people edit the same record, when a customer returns half an order, or when the data you import is messy.

When you evaluate business software, ask to see your own awkward cases, not the vendor's best ones. Our guide to evaluating business software has a practical trial plan for this.

Lesson 2: delays usually come from scope and testing, not from the exciting part

The Roadster was promised for 2020 and is now planned for 2028. We do not know the reasons inside Tesla, and we will not guess. But the pattern is familiar in software: the visible feature is rarely what takes the time. Integration with everything around it, edge cases, safety, rules and long testing take the time.

If you are planning a custom system, the same applies to you:

  • Write down the dull parts of the scope: data migration, user roles, reports, what happens when something fails.
  • Build in stages, so something real is in use early.
  • Do not accept a date without knowing what testing is included.

Our post on what drives custom ERP cost covers how scope shapes both price and timeline.

Lesson 3: test before you release, because users find problems fast

A product that fails in front of customers costs far more than one that was tested first. For business software, that means checking the real workflows: stock counts that must match, invoices that must add up, permissions that must hold. This is the work of software QA and testing, and it is cheapest before launch, not after.

Lesson 4: measure a claim before you believe it

"0 to 60 in a second" is a number. Whether it holds in everyday use is a separate question, and it takes independent measurement. Your business has the same issue with its own numbers. If stock levels, sales and cash are spread across spreadsheets, nobody can say with confidence what is true today. Our guide to how to track inventory for a small business shows what a single source of stock truth looks like, and replacing spreadsheets with custom software is the route when the spreadsheets are too tangled to untangle.

A data visualization dashboard built on one trusted source of data lets you check claims, yours included, against what actually happened.

Where a ready-made system fits

Not every business needs something new or exciting. Many need inventory, sales and accounts to simply work, every day, with numbers that agree. That is what our own product, IDP, is for: inventory, sales and accounting software for small and medium businesses, with multiple warehouses, customer and supplier balances, and reports. Plans are listed on the pricing page. It works as an offline-first desktop system, with a cloud-hosted option available. It does not do everything. For example, payroll and manufacturing workflows are not part of it. If your needs go beyond that, a custom ERP built to your requirements may fit better.

The takeaway

A great demo is a good start. It tells you nothing about dependability, timeline or cost. Whether you are buying software or having it built, ask for proof on your own data, a staged plan, and testing before release.

If you want a second opinion on a software plan, or want to see IDP with your own stock and sales data, talk to us.

FAQ

Does Wellsoft have any connection to Tesla or Elon Musk?

No. This post comments on public news coverage. We are not affiliated with, endorsed by or partnered with Tesla, SpaceX or Elon Musk.

What can a product demo not tell you about delivery?

A demo is prepared to work under ideal conditions. Real use includes messy data, mistakes, slow connections and several people at once. Ask to test your own cases before you decide.

What should I ask a software vendor about delivery dates?

Ask what the date includes: data migration, testing, training and support. Ask what is delivered first and what comes later, and what happens if the date slips.