Software development

Software for companies where a failed system or a wrong output costs money, written by the engineer who scopes it.

What this practice covers

Four kinds of software work, each scoped once you have said what your systems do and where the risk sits.

Legacy system modernization
Replacing an ageing system in stages while it stays live, so the work depending on it is never taken down in one move.
Custom software development
Building software for a job no product covers, proven on cases with known answers before anyone relies on its output.
AI and machine learning development
Putting a language model or a learned model to work on your company's data, measured on real cases before it goes live.
DevOps consulting
Helping a team ship software more often without each release carrying risk, with a return path kept ready.

How the services fit together

A software engagement rarely stays inside one of these four. An old system is usually replaced while the business keeps using it, and each new part needs a way to reach production safely. Sometimes one of those parts is a model that reads documents nobody has time to go through. The services are listed separately so you can find the one closest to your problem, and the brief is where the right combination gets worked out.

Amos introduced AI and text analytics at a Fortune 500 company years before ChatGPT, building natural language processing and text-mining tools that its marketing, R&D and strategy teams worked from. At OurCrowd, Micky Sapir, Vice President of Product, noted his ability to build AI into the team's workflows while most of the industry was not yet thinking about it.

Who does the work

Amos Weiskopf

Amos Weiskopf has built software for more than two decades, and he can write each part he proposes himself.

Questions buyers ask

What does software work cost?

It depends on what has to be built or replaced. Amos prices it once he has read your brief.

How do I start a software engagement?

Write a short brief on what the software has to do and what would hurt most if it went wrong. Scope and price are worked out from that.

Which of these services do I need?

If you are not sure, describe the problem in the brief. Many projects draw on more than one service, and the brief is where the right mix is settled.

Do you advise, or build?

Both. Amos can review a plan or a codebase and say what he would change, and he can build the changes himself.

Engagements by written brief.

Work begins from a documented problem statement, not a sales call.

Write a brief.

It goes straight to Amos.

Or email amos@tevelis.com, or book a meeting.