Excel has become the operating system
Lists get copied, files get sent, the same information is maintained in three places. Nobody knows for certain who has the current version.
Jonas Schmitz · software developer in Koblenz, Germany
For companies where someone
retypes the same things every day.
I am Jonas Schmitz. I build you a program that takes over the typing: timesheets, orders, the lists that get keyed by hand from one file into the next. Checking and approving stays with you.
- One developer, not a team. You talk to the person who builds it.
- Weekly releases to a real environment
- The finished program is yours, source code included.
Today, and afterwards
The same order, twice.
On the left today's steps, each one marked as done by a person. On the right the same stretch when a program takes the repetitive steps. An example — no completed customer project.
Emailed PDF orders become checked orders, with human approval where it counts.
Today
How the process runs if nobody changes anything.
- 01Email arrives in the mailboxSystem
- 02Open the PDF attachmentHuman
- 03Look up the customer recordHuman
- 04Look up article numbersHuman
- 05Retype the line itemsHuman
- 06Check prices and termsHuman
- 07Raise a query by emailHuman
- 08Create the order in the systemHuman
- 09Write and send the confirmationHuman
With NeXsoft
The same process, with the decision at one clear point.
- 01Email captured automaticallySystem
- 02Attachment read and structuredSystem
- 03Validated against master dataSystem
- 04Deviation raised for approvalHuman
- 05Query with the customer, case visibly waitingHuman
- 06Order created in the systemSystem
- 07Confirmation drafted for sendingSystem
The label Human marks the points where a person decides or enters something. System marks the steps the application takes over. The human approval deliberately stays in place — it is not optimised away.
Starting point
Where unnecessary work arises today.
Information travels from system to system
Email to PDF to Excel to ERP to CRM. Every transition is manual work, and every piece of manual work is a place where something gets lost.
Staff search for knowledge that already exists
The answer sits in a manual, an old email or a colleague's head. Just not where someone is asking for it.
Standard software does not fit the actual process
So staff build detours around the software — side lists, note fields, conventions that are documented nowhere.
Growth mainly produces administration
More customers and more cases automatically mean more manual work, because the process does not scale with the volume.
The systems hold data, but no common process
Each one works on its own. The case that runs through all of them exists only as habit in the heads of the people involved.
None of these conditions comes from poor work. They arise because the process grew and the software never followed it. Recognise one of these? Then show it to me.
Four specialisations
Where custom software makes the difference.
Four areas I work in. Each begins with a process that takes more manual work today than it needs to.
01
Custom Business Software
When an important process in your organisation only works around the standard software you have: extra spreadsheets, emails and verbal agreements.
Input
- spreadsheets
- scattered tools
- coordination by email
- paper forms
- conventions without a system
Result
- one central application
- roles and permissions
- approvals with a record
- reporting from live operations
- traceable changes
When standard software does not map an important business process properly, I build the software that does.
02
AI Process Automation
When the same clerical work starts over every day: read, transfer, check, forward.
Input
- emails with attachments
- orders and forms
- recurring enquiries
- receipts and supporting documents
- data from existing systems
Result
- pre-sorted cases
- captured and checked data
- prepared replies
- approval by a member of staff
- a traceable record
I automate the steps that are repeated by hand every day, and leave the decision with a person at one deliberately chosen point.
03
AI Assistants, Knowledge & Document Intelligence
When the same everyday questions get researched from scratch again and again although the answer already sits in documents and systems.
Input
- PDF documents and manuals
- contracts, quotations and invoices
- email threads and enquiries
- technical documentation
- approved company knowledge
Result
- an answer with a source reference
- the passage instead of the file name
- a summary across several documents
- an answer that does not depend on who happens to be available
- an assistant inside the daily process
I build assistants that answer questions from your own documents — and say which document the answer came from.
04
Technical Operations
When the work happens at the machine, in the vehicle or at the customer's site — while the documents needed for it sit back in the office.
Input
- asset and site data
- service history
- technical manuals
- photos from the job
- inspection and maintenance rules
Result
- work instructions at the asset
- service report from the job
- photo documentation attached to the case
- inspection record with time and person
- feedback into the authoritative system
Whoever is out on the job has everything with them: the work order, the documentation for the asset and the data from your systems — in one application built to keep working without a network connection.
You cannot buy this ready-made. What gets built follows the way your company works.
Process schematic
From inbox to system
An order arrives as a PDF by email. At the end the order is entered and the confirmation is written. What happens in between is what the diagram shows — on its own or step by step.
- Starting point: four input channels, four systems, nothing is running.
- An email arrives and is captured.
- The attachment is recognised as a document and read.
- The required fields are extracted: customer number, line items, delivery date.
- The details are checked against the master data. One discrepancy remains open.
- The open discrepancy goes to a person for approval. Nothing proceeds without that approval.
- After approval, the existing systems are updated.
- Order and confirmation are created automatically.
- Result: the case is complete, and the person decided once instead of retyping eight times.
Input
Emailwaiting
PDFwaiting
Formwaiting — exists, but does not occur in this example
Photowaiting — exists, but does not occur in this example
NeXsoft
Understandwaiting
Checkwaiting
Automatewaiting
Connectwaiting
Your systems
ERPwaiting
CRMwaiting
Databasewaiting
Portalwaiting — exists, but does not occur in this example
Result
Orderwaiting
Confirmationwaiting
Reportwaiting — exists, but does not occur in this example
Replywaiting
Customer number
Line items
Delivery date
Approval by a personon every discrepancywaiting
Input
Emailwaiting
PDFwaiting
Formwaiting — exists, but does not occur in this example
Photowaiting — exists, but does not occur in this example
Customer number
Line items
Delivery date
NeXsoft
Understandwaiting
Checkwaiting
Automatewaiting
Connectwaiting
Approval by a personon every discrepancywaiting
Your systems
ERPwaiting
CRMwaiting
Databasewaiting
Portalwaiting — exists, but does not occur in this example
Result
Orderwaiting
Confirmationwaiting
Reportwaiting — exists, but does not occur in this example
Replywaiting
Schematic representation of a typical process. No customer data, no measurements. Outlined with a dashed border: routes that would exist just as well — this example case simply does not take them.
Existing systems
Your ERP stays your ERP. I build the path in between.
The most common task is not to replace a system — it is to build the stretch a person covers today by copying and pasting. Click a building block.
Your systems
stay where they are
NeXsoft
the path in between
Recipients
People and systems
Your systems
stay where they are
NeXsoft
the path in between
Recipients
People and systems
Select a building block to see what actually happens there.
No existing system is replaced: your ERP, CRM and line-of-business software stay authoritative for the data they hold, and the layer in between builds the path a person currently walks with copy and paste.
Working together
How a project runs — and what happens when something breaks.
Step 01
Specification
Data model, role matrix, interface list and acceptance criteria are set down in writing before anything is built. Can be commissioned on its own — the result is still usable if someone else builds it afterwards.
A document that works as a basis for tendering
Step 02
Build
Weekly delivery to an environment your department can operate itself. No change goes live unchecked: every one runs through automated controls before it is released. For your project, tests on the business-critical paths are added.
You see the current state weekly, not at the end
Step 03
Replacing legacy systems
Migration in parallel operation: the legacy system stays authoritative until the handover has been reconciled and logged. For every cut-over step, the fallback scenario is defined in advance.
A way back at every step, not only at the start
Operations and response times
- Service hours
- Mon–Fri, 9am–5pm
- Outage, operations halted (P1)
- Response < 4 hours
- Restricted operation (P2)
- Response < 1 business day
- Defect without operational impact (P3)
- with the next release
- On-call outside those hours
- no — deliberately not promised
These values are written into the contract. They are set so that I can keep them — a 24/7 commitment from me would not be credible.
Handover is built in, not bolted on
A project is yours from the first week of work, not from the final invoice. That is why it is set up from the outset so another team could take it over at any time:
- Source code and infrastructure run in your organisation from day one, not in mine.
- Every architecture decision sits in the repository as a dated document, including the alternative that was rejected.
- A written operations guide — how the software runs, how it is restarted and how a change is deployed — is part of what we deliver, not of the closing meeting.
- On request, before the project starts, I name a stand-in from my partner network who can take over the current state.
Blueprints
No client references. Full disclosure instead.
Five systems as I would build them — with process, architecture, integrations and the metrics you would have to measure them against.
Solution blueprint: a fully worked example system, not a delivered client project. The processes, architectures and metrics show how I would build such a system — they are not measurements.
That depends heavily on how much of your work is manual today. The biggest gains come from recurring tasks: tickets, emails, reports, classification, routing. I do not estimate blindly — in the intro call we look at your specific process, measure the current state and define in advance how success will be measured.
Intro call
Show me what you retype.
Describe something that runs by hand at your company every week. I tell you whether software is worth it — and if it is not, I say so.
Free, without obligation, with a non-disclosure agreement if you want one.