Your problem isn’t technology. It’s the time it eats.

I look at what happens several times a week in your business and rebuild those steps so they run without you.

What I build.

It almost always starts with a process that runs by hand every week. I build what hangs off it too, which is why this list doesn’t stop at automation.

Processes: The usual case. A task that repeats every week and follows fixed rules runs without you afterward: data from the inbox into the next program, recurring documents, appointments kept in two places at once.
Web applications: When the process is missing the piece everything else hangs on: a form that gets the data in digitally in the first place, an overview where your team can see where things stand, a page where customers check for themselves instead of calling.
Websites: I still build these, on their own too. Usually with a CMS behind them: write posts, change text, swap images, without asking a developer every time. And if a website is all you need, with no process behind it, that’s an ordinary job, not a special case.
Small programs: Sometimes the answer isn’t an application but a tool that does one single thing: convert a file, prepare an export, reconcile two lists. If that solves it, I build that and nothing more.

Where the solution runs.

The finished process runs on an environment from SW labs, set up, maintained and kept current. You don’t have to deal with it. If you have a server of your own or would rather rent one, it runs there just as well. What applies in your case is settled before we build, and it’s in the proposal.

When it doesn’t pay off.

Not every process is a fit, and not every business needs me for it. Five cases where I’ll talk you out of it in the first call. Then you’ve spent an hour and not placed a job.

Too rare: A process that comes up twice a year is done faster by hand than with a program that needs maintaining. It isn’t the length that counts but how often times how long: five minutes a day is twenty hours a year.
Different every time: If someone has to look and decide every time, there’s nothing to automate. What’s left is the groundwork: gathering everything so the decision takes a minute instead of ten.
Still on paper: No program can read what’s on a notepad at the counter. Another project comes first then, with its own work and its own price, and I say so up front, not halfway through.
Nothing gets out: Some programs hand their data off to others on their own, older ones often can’t. Whether yours can is something I check before I quote a price. Days of work hang on it.
Someone’s already on it: If you already work with an IT provider, the automation sensibly belongs with them. Whoever already looks after your programs can get to them faster than I can.

What clients want to know up front.

Do I have to switch my programs for this?

Usually not. I build around what you already run. If a program can’t be reached at all, I say so. Switching is then your call, not mine.

Where is my data stored?

Usually on an environment run by SW labs. I set it up, keep it current and look after it so you don’t have to. If you have your own server or would rather rent one, it runs there just as well. What applies in your case is settled before we build, and it’s in the proposal.

You’re one person. What happens if you’re out?

Fair question for a one-person business. What I build is made of components you’ll find everywhere, it’s written down and it can be moved somewhere else. Another developer can pick it up without starting over. You’re not tied to SW labs to keep it running.

Do you also work outside the region?

Yes. Most of the businesses I build for are in Aschaffenburg and the surrounding area. That’s not a requirement.

Getting started is simple.

I listen, and I tell you whether anything can be done about it. Sometimes the answer is no. Then you’ve lost 45 minutes. So have I.

Book a first call