Built around real-world problems.
Most rebuilds do not start with bad code. They start with a brief that left out something the business already knew. Oryon9 builds custom web and mobile apps, SaaS platforms and AI systems, and it also builds and runs its own software products. These five questions come from that work. Answer them on paper before you ask anyone for a quote, including us.
1. What problem are you solving, and how is it handled today?
Write one sentence that begins "Right now, [who] has to [do what], and it goes wrong when [this happens]." Then write down the current workaround: the spreadsheet, the shared inbox, the whiteboard, the phone call.
Why it matters: the workaround shows what the software must replace, and what people will keep using if the new tool is slower than what they have. If you cannot describe the problem without naming a feature, the feature is still a guess.
Bring to the first conversation: your one-sentence problem and a list of the steps in the workaround.
2. What must version one do, and what can wait?
Split your wish list into three columns: "the work cannot happen without it", "helpful soon" and "later". Version one is the first column only.
Why it matters: a long first release delays the day you learn how people actually use the tool. A short, honest first release lets real use decide what comes next.
Bring: the three columns, with every item written as an action a person takes, such as "a dispatcher assigns a job", not as a technology.
3. Where does the data come from, and who owns it?
List every piece of information the app will hold. For each, note where it starts (typed in, imported, another system), who is allowed to change it, and whether you need to get it back out later in a usable format.
Why it matters: data decisions are the hardest to change once people are using the app. Ask early about export, backups, and what happens to your data if you change suppliers.
Bring: a list of your data types and the systems they live in today.
4. Who will use it, where, and on what?
Name the real roles: office staff, field staff, managers, outside parties. For each, say where they work (desk, vehicle, a site with poor signal) and on which device.
Why it matters: software that suits a desktop in an office can fail on a phone in the field. Field and operations tools in particular need to be designed around the conditions of use. Oryon9 learns this from operating its own products, including SiteEvo, our property and field operations platform, which is in early access and in daily operational use.
Bring: your list of roles with location and device for each.
5. Who runs it after launch?
Decide who answers questions, fixes problems, applies updates, manages user accounts and handles security. An app is a running system, not a finished object.
Why it matters: unclear ownership after launch is how a good build slowly stops fitting the business. If an AI component is involved, add one more question: who checks its output, and what happens when it is wrong? Not every problem needs AI, and a plain workflow is sometimes the better answer.
Bring: a named owner for the system, even if it is you.
A one-page checklist
- One sentence describing the problem, plus today's workaround.
- Version one in three columns: must, soon, later.
- Data types, their sources, who edits them, and how you get them out.
- Roles, locations and devices.
- Who owns the system after launch, and who checks any AI output.
If you can fill in all five, any developer, including us, can give you a much more useful conversation and a more realistic scope. If you cannot yet, that is useful to know before money is spent.
Your business problem. Our technology.
Have a project in mind? Tell us about your project through the contact form at oryon9.com.
Oryon9 is an independent technology company. It develops and operates its own software products, builds custom applications and AI systems, and licenses technology to businesses and entrepreneurs.