What this software needs to solve
Giving an application a browser screen and changing how the business process works are different projects. A useful buying guide makes that difference clear before the development estimate grows.
Compare the buying decisions
| Decision | What changes the choice |
|---|---|
| Project scope | Separate interface work, workflow changes and new integrations. |
| Business logic and dependencies | Compare where programs, validation and transaction control will run. |
| User experience and deployment | Test the required browser, devices and user roles. |
| Development and maintenance | Compare team skills, testing and the process for publishing a change. |
What should change for the person using the application?
A warehouse user may need a clearer screen for an existing task. A customer portal may need a new sign-on, a different workflow and data from several systems. These are different scopes even when both use a browser.
We would choose one important business transaction for the trial and agree what should remain in the existing application.
Which existing rules must the new interface preserve?
An established RPG application can contain rules that are easy to miss by looking only at its screens. The demonstration should follow a transaction through its validation and updates.
Shared programs, database access and external calls belong in the inventory. Our application-porting guide covers a broader platform change when that is also being considered.
Can the result work where staff will use it?
A desktop demonstration may not show how a screen behaves on a handheld device or with a different keyboard workflow. We would use the environment and accessibility needs relevant to the people doing the work.
Authentication, authorization and external access need an agreed design. A browser interface should receive the same attention to data permissions as the existing application.
Who will support the application after launch?
The first completed screen is only part of the cost. The buyer also needs to know who can change it, how a change is tested and how the team recovers from a bad release.
We would include source ownership, licenses and deployment environments in the proposal. That keeps the tool choice connected to the people who will maintain the result.
A useful trial before the purchase
We would build the demonstration around representative work from your environment.
- Build a representative transaction and compare the result with the existing application.
- Use the prototype with the required user role, device and browser.
- Change a business rule, test it and demonstrate the agreed release and recovery process.
What belongs in the software quote
A clear proposal connects the license to the installation and the work your team will run.
- Business transactions, screens and integrations in scope.
- IBM i release, existing application structure and runtime requirements.
- Developer skills, environments, licenses and source ownership.
- Testing, security design, training and ongoing maintenance.
Midland software and product context
Our RPG and web-development catalog lists Profound Logic - RPGsp and Profound Logic - Genie. The current edition and proposed approach need to be matched to the application, skills and deployment requirements in your project.
Catalog and product context checked October 23, 2026. The proposal identifies the edition, licensed scope and supported configuration being offered.