A guide to hiring a Webware developer
Webware for Python is a web framework from an earlier era of Python. Some businesses still run important tools on it: internal systems, customer portals, reporting pages. These apps often work well enough that nobody wants to touch them, until a server is replaced or a Python version stops getting updates. A Webware developer is hired to keep such an app safe and to help plan its next step. The sections below explain the role and how to judge candidates. They are written for owners and managers who inherited a Webware app and need a steady pair of hands.
What a Webware app looks like
The framework is built around a few ideas. A request arrives at the application, which passes it to a servlet, and the servlet builds a response. Pages can also be written as Python Server Pages, where code and markup sit together. The framework offers sessions and scheduled tasks. A developer who understands this model can find where a page is built, where data is read and where a bug may hide.
Is this the role you need?
The word webware is sometimes used loosely for any web software. If you want a new website or web app in any language, a web developer is the right search. If your code is Python but built on a different framework, a Python developer fits better. Choose a Webware developer when your app really uses this framework and you need someone who can read it.
Typical projects
- Fixing bugs in an app nobody on staff wrote.
- Moving old code to a supported Python version.
- Putting the app behind a standard web server using WSGI.
- Reviewing security and replacing unsupported libraries.
- Planning and starting a move to a newer framework.
If the app is small and rarely used, a short audit may be all you need. A developer who recommends the smaller job is looking after your budget.
Start with an audit
Before changing anything, ask the developer to look around. Where does the app run? Which Python version does it use? What libraries does it depend on? Which pages do customers use daily? A short written audit answers these questions and lists the risks in order. It also gives you a fair basis to compare keep, upgrade and replace.
Reading a candidate’s background
Ask about older systems the person kept running and what they changed first. Good answers mention tests, backups and small releases. Direct experience with this framework is a plus but is rare, so look for the habits behind it: patience, curiosity and clear notes. Be careful with anyone who wants to rewrite everything on day one.
Questions to ask in interviews
- How would you learn an unfamiliar servlet-style app in your first week?
- What would you test before moving it to a newer Python?
- How do you keep a live site working during an upgrade?
- When would you advise a rewrite, and when would you not?
- What notes do you leave for the next engineer?
Listen for specific examples. Be wary of answers that promise a quick fix without looking at the code first.
Try a paid mini project
Give each finalist a small, real task: fix one known bug, or write tests for one important page. Pay for the time. Then compare how the person approached the code, how clearly they reported what they found and whether the change is easy to review. A short test shows more than a long conversation.
Plan the long term
Decide early whether the goal is to keep the app steady, to modernize it or to replace it. Each goal needs different skills and a different budget. Keep the code, the servers and the logins in accounts your company owns. Ask for a simple map of the app and a list of its scheduled tasks, so that knowledge does not live in one head.
Working with your team
Introduce the developer to the people who use the app. They know which pages matter most and which quirks are really rules. A brief weekly update and one shared list of tasks keep the work visible. Release small changes and keep a way to roll back each one.
What to expect in the first month
In the first weeks, expect a written audit, a working copy of the app on a test server and a short list of risks in order of urgency. Next come small fixes and the first tests. Larger moves, such as a new Python version or a new framework, are planned once the team has seen how the app behaves. This pace keeps customers safe and gives you facts to decide on.
Common mistakes
- Upgrading Python without any tests in place.
- Starting a rewrite before the old rules are written down.
- Leaving all the knowledge with one person.
- Ignoring libraries that no longer get updates.
Looking at a wider role? Take a look at our Python developers for general Python work, or our web developers for new sites and apps.