01
For customers
Read the services, see the hours, call the office, and send a request the business has agreed to take.
Mobile apps
Salix26 builds mobile apps for customers and for the office. The app lists the services, hours, and contact paths the business already uses, so the phone and the website do not tell two stories.
01
Read the services, see the hours, call the office, and send a request the business has agreed to take.
02
The jobs, the contact details, and the service list the business already runs, in a pocket.
03
The app is built for both. The scope is the work the business named, not a generic store template with the logo swapped.
We start with who opens the app and what they need to do. A customer app might show services, hours, and a way to ask for a listed service. An office app might show the work the business already tracks. Features that need data the business does not have are left out until that data exists.
The website can stay the public record while the app handles the repeated task: requesting a service, checking hours, or seeing the day’s jobs. Both use the business name, the services, and the contact details.
The business name, who the app is for, the tasks it should cover, and whether it is for iPhone, Android, or both. If a website is already part of the work, the app follows that service list.
No. It shows the services the business offers. A request in the app is for work the business has agreed to take.
Yes. Many projects start with the website because that is the public record. An app can also be the first piece, as long as the services and the contact details are known.