Services
Software development
Development at VYN IT is an interface or a small tool when the software you already have does not cover the process. First we check whether a setting, an export or an existing product is enough. New code follows only when the process is stable and someone will pay to keep it.
Development at VYN IT is an interface or a small tool when the software you already have does not cover the process. First we check whether a setting, an export or an existing product is enough. New code follows only when the process is stable and someone will pay to keep it.
Who owns the engagement and the code is in the order before the first line. We do not build an application only one person may touch, and we do not replace a spreadsheet for the sake of replacing it.
What we do
Interfaces
Data from the business software into another system, or back, with a run someone can follow and an error someone sees.
Small tools
A process that is copying, renaming and an error-prone list today, as a program someone can follow.
Check before building
If the standard software can do the step, we set that up. Development is the path when that is not enough.
Handover
Where the code sits, how to start it, which accounts it uses. Not only on the machine where it was written.
Changes afterwards
A follow-up order when the process changes. No quiet extra building without a scope.
Technologies and solutions
The business software you have
Exports, imports and the interface the vendor already provides.
Scripts and small services
Where a scheduled run is enough and a platform of its own is not.
Microsoft 365 and files
When the process starts in a mailbox, SharePoint or a share.
Accounts with few rights
The program gets what it must read and write, not an admin account.
What you gain
Less manual work
A run replaces the error-prone list when the process is actually stable.
No product for its own sake
What the current software can do is not rebuilt.
The code can be found
It does not sit only with one person and only on one laptop.
Failures are visible
A run that fails reports itself. It does not end quietly with half a file.
Typical problems
The spreadsheet is the process
Five people keep five versions, and none of them counts.
The vendor already has an interface
It was never set up, and new code is requested anyway.
An admin account in the script
The password sits in clear text in a file on the desktop.
Nobody can change it
The person who wrote it has left, and there is no copy of the code.
How we work
- 1
Advice
We look at the process and whether an existing product or export is enough.
- 2
Planning
Scope, ownership of the code, low-right accounts, and how an error is reported.
- 3
Implementation
Build, and a run with real sample data from your setup, not invented customers.
- 4
Optimization
What snags on a real run is fixed before it becomes daily work.
- 5
Ongoing care
Running the job, if you order that: a report on failure, a change only with a scope.
Frequently asked questions
Do you turn every spreadsheet into software?
No. First we check whether an existing application or an interface is enough. New code pays off when the process is stable and someone funds the upkeep.
Who owns the code?
That is in the order before anything is written. Without it you get an application only one person may touch.
Do you look after the software afterwards?
If that is ordered. A failed run should report itself. New wishes are a new scope, not quiet extra features.
Do you build large products?
No. Interfaces and small tools around the IT we look after. Not a standalone product with a market of its own.
Which language do you use?
The one that fits the process and what already runs and can be maintained. The language is not the sales argument.
Contact and advice
Call us or send an inquiry. We reply on business days and say whether and how we can help.
+43 1 996 96 33