100 questions, answered

Send us a short description of what you want to build and the problem it solves. We reply with questions, book a call inside your business hours and then propose a discovery phase or a scope.

A rough outline of the goal, who will use the software and any systems it must connect to is enough. Existing documents, screenshots or competitor examples help but are not required.

A short, paid piece of work where we map requirements, users, integrations and risks. It ends with a written requirements document and a fixed quote or a recommended team shape.

Yes. We build first versions for start-ups and extend or replace systems for established companies, and the process is the same: agree scope in writing, then build.

Yes. We can work alongside an in-house team, take on a defined part of the product, or extend an existing codebase after reviewing it.

We work remotely with businesses worldwide. Calls and releases are scheduled inside your business hours, and scope and updates are written in plain English.

That is common. Discovery turns the idea into a written specification, with priorities agreed so the first release covers what matters most.

It depends on scope and current commitments. We give you a realistic start date in the proposal rather than promising one before we understand the work.

We use three models: a fixed quote for clearly scoped work, a monthly fee for a dedicated team, or time and materials billed hourly. We recommend the one that fits how well defined the work is.

After discovery, once the requirements document is agreed. The quote is tied to that document, so both sides know exactly what is included.

You get a team of agreed roles working on your product each month for a monthly fee. You set priorities and can scale the team up or down with notice.

When requirements are likely to change or the work is exploratory, such as research, support or ongoing improvements. You are billed for hours worked, with regular reports.

Payments are split into milestones tied to agreed deliverables, typically a deposit at the start and further payments as each stage is demonstrated and accepted.

We write up each change request with its impact on cost and timeline, and nothing changes until you approve it in writing.

Yes. We can work under our terms or yours, and we are happy for your legal advisers to review them.

We invoice in your currency where possible, including USD, GBP, EUR, AED, SAR, CAD, AUD and SGD.

Users and roles, features and acceptance criteria, integrations, non-functional needs such as security and performance, and what is out of scope. You approve it before the build starts.

We work in two-week sprints. Each sprint has an agreed set of tickets, and ends with a demo of working software.

You see a live demo every two weeks, and you can access a staging environment in between to try features as they land.

Yes. A project manager owns your project, runs the sprints and demos, and is your main contact for questions and decisions.

Usually Slack or Microsoft Teams for messaging, Jira or Linear for tickets and GitHub for code. We can use your existing tools if you prefer.

We schedule calls, demos and releases inside your business hours and keep work moving between calls through written updates and tickets.

Plan for someone to attend the fortnightly demo, answer questions within a day or two and approve changes. Faster answers mean faster delivery.

We raise it early in writing, explain the cause and propose options, whether that is reprioritising, adjusting scope or changing the timeline.

We choose mainstream, well-supported technologies that fit your requirements, your existing systems and the skills available to maintain it later. The reasoning is written into the requirements document.

Yes. We build features such as document processing, search over your own content, chat assistants, classification and summarisation using large language models, with the use case and success measures agreed first.

We work with the major commercial model providers and open-source models, and pick based on quality, cost, latency and where the data can be processed.

We use providers and settings that do not train on your data where that option exists, send only the data a task needs, and can use models hosted in your own cloud account for sensitive work.

We ground answers in your own data, add guardrails and human review where it matters, and test against real examples before launch. No model is perfect, so we design for checking rather than blind trust.

Yes. We review the existing system, then usually replace it in stages so the business keeps running, with data migrated and checked at each step.

Yes. We connect CRMs, ERPs, accounting, payment and logistics tools through their APIs, webhooks or file exchanges, and document each integration.

Yes. We set up hosting, CI/CD pipelines, monitoring and backups on AWS, Azure or Google Cloud, in accounts owned by you.

You do. Code sits in repositories in your name, and the intellectual property is assigned to you under the contract as the work is paid for.

Yours. Cloud, domain, third-party service and app store accounts are set up in your name, and we are given access to work in them.

Yes. We are happy to sign an NDA before you share any details of your idea or business.

Yes. Where we handle personal data on your behalf we sign a data processing agreement, including international transfer terms where they apply.

Each team member gets individual accounts with only the access they need, protected by multi-factor authentication, and access is removed when they leave the project.

Yes. We follow secure coding practices, review code, scan dependencies and test against common vulnerabilities such as the OWASP Top 10. We can also support an independent penetration test if you commission one.

Yes. We build apps for both platforms, and usually the web or admin system behind them as well.

Cross-platform frameworks such as React Native or Flutter suit most business apps and share one codebase across both platforms. Native development makes sense when you need heavy device features or maximum performance.

Yes. We prepare builds, store listings and review notes, submit them and deal with any feedback from Apple or Google.

Yours. The Apple Developer and Google Play accounts are registered in your name, so you own the listings, reviews and customer relationship.

We read the reviewer's notes, make the required changes and resubmit. Following the store guidelines from the start keeps rejections rare.

We release updates through the stores on an agreed schedule, and can use staged rollouts so problems are caught before every user gets the new version.

We monitor the release closely, fix any issues that appear and hand over documentation. Most clients then move to a support or ongoing development arrangement.

Yes. Fixed-scope projects include an agreed warranty period after launch during which defects against the requirements document are fixed at no extra cost.

Typically bug fixes, security and dependency updates, monitoring, backups and small improvements, agreed in a support plan with response times written down.

Yes. Many clients continue with a dedicated team or time and materials to add features in the same two-week sprint cycle.

Yes. You already own the code and accounts, and we provide documentation and a handover to your team whenever you choose.

Yes. We start with a code and infrastructure review, report what we find, then take over support once the risks are understood.

RAG, or retrieval-augmented generation, is a technique where an AI model first searches your own documents or data and then writes its answer using what it found. It keeps answers current and specific to your business without retraining the model, and lets each answer cite its sources.

Yes, AI can read invoices, receipts and similar documents and pull out fields such as supplier, dates, line items and totals into structured data. Accuracy is high on clear documents, and a well-built system flags low-confidence results for a person to check before they reach your accounting software.

A chatbot answers questions in conversation, while an AI agent can also take actions, such as looking up records, updating systems or completing multi-step tasks. Agents need tighter permissions, logging and human approval for important steps, because their mistakes change things rather than just words on a screen.

Most businesses should start with RAG, because it grounds answers in their own up-to-date content without retraining anything. Fine-tuning is better for teaching a model a consistent style, format or specialised task, and the two are often combined. At Quoryx.AI we test both against real examples before recommending one.

Small businesses get the most value from AI by automating repetitive work such as answering common customer questions, drafting emails and quotes, sorting documents and summarising reports. Starting with one well-defined task that takes staff hours each week gives a clear, measurable result before investing further.

An AI hallucination is when a language model produces an answer that sounds confident but is false or made up. It happens because models predict likely text rather than look up facts, so reliable systems ground answers in trusted data, show sources and route uncertain cases to a person.

Measure AI return on investment by comparing a baseline, such as hours spent, error rate or response time, before and after the feature goes live. Agree those measures before building so success is objective. Quoryx.AI writes the success measures into the requirements document for every AI feature.

Yes, you can have a private assistant that answers questions from your own policies, manuals and knowledge base. It is usually built with retrieval-augmented generation, respects user permissions so people only see documents they are allowed to, and can run with providers that do not train on your data.

A vector database stores text, images or other content as numerical representations called embeddings, so it can find items by meaning rather than exact keywords. It is the component that lets an AI assistant quickly locate the most relevant passages in thousands of documents before answering.

Yes, if AI handles routine questions well and hands over to a human quickly when it cannot help. Good support automation answers from your real help content, knows its limits, passes the full conversation to an agent on handover and is measured on resolution and satisfaction, not just deflection.

An AI proof of concept is a short, focused build that tests whether AI can do a specific task well enough on your real data. It typically takes a few weeks and answers the key question, such as accuracy on your documents, before you commit to a full production system.

In most businesses AI changes jobs rather than replacing them, taking over repetitive tasks so people can focus on judgement, relationships and exceptions. The best results come from designing the workflow around people reviewing and improving AI output. At Quoryx.AI we map the current process with the team who does the work first.

The cost of building an app depends mainly on the number of features, the platforms, integrations with other systems and the design detail required. A focused first version typically takes 8–12 weeks, while complex platforms take several months. Quoryx.AI gives a fixed quote after a discovery call and an agreed requirements document.

A business website typically takes 4–8 weeks to design and build, depending on the number of pages, content readiness and any custom features. Sites with e-commerce, bookings or integrations take longer, and waiting for content is often the biggest cause of delay.

A mobile app usually takes 3–6 months from discovery to store launch, with a focused first version often ready in 8–12 weeks. Timelines depend on features, the back-end system behind the app, integrations and the time needed for App Store and Google Play review.

An MVP, or minimum viable product, is the smallest version of a product that solves the core problem well enough for real users to try it. A focused MVP typically takes 8–12 weeks to build, and its purpose is to learn from actual usage before investing in more features.

Software quotes vary because agencies make different assumptions about scope, quality, testing, design and who handles hosting and support. A low quote often leaves things out that reappear later as change requests. Comparing quotes against the same written requirements is the only fair way to judge them.

Ongoing software costs depend on hosting and third-party services, the number of integrations, how often dependencies need security updates and how many improvements you want. Plan for maintenance as a permanent part of owning software. At Quoryx.AI we agree a support plan with the scope and response times written down.

Software projects usually overrun because of unclear requirements, scope that grows without being re-planned, slow decisions and integrations that turn out harder than expected. A written requirements document, fortnightly demos and a formal change process catch these problems early, while they are still cheap to fix.

The most effective way to reduce development cost is to shrink the first release to the features that matter most and use proven off-the-shelf services for things like payments, login and email. Clear requirements and quick decisions also save time, because rework is the largest hidden cost.

Adding a single AI feature to an existing product typically takes 4–8 weeks, including a short proof of concept on real data. The time depends on data quality, how the feature connects to current systems and how much testing and human review the use case needs.

A custom CRM or client portal typically takes 2–4 months for a first release, depending on user roles, workflows, reporting and integrations with email, accounting or payment systems. Quoryx.AI shows working software every two weeks, so you can use and shape the system before it is finished.

An SEO-friendly website is fast, mobile-friendly, secure and easy for search engines to crawl, with clear page titles, headings and useful content that matches what people search for. Clean URLs, internal links, an XML sitemap and structured data help search engines understand and rank each page.

Core Web Vitals are Google's measures of real-user page experience: how quickly the main content loads, how fast the page responds to interaction and how stable the layout is while loading. They are a ranking signal and are improved by optimising images, scripts, fonts and server response times.

A headless CMS is a content management system that stores and edits content but does not control how it is displayed, delivering it through an API to a website, app or any other channel. It suits businesses publishing the same content in several places or wanting a fast, custom front end.

Most businesses should start with a responsive web app, because it works on every device without app store downloads and is quicker to update. A mobile app is worth it when you need push notifications, offline use, device features such as the camera, or frequent daily use by loyal customers.

A progressive web app, or PWA, is a website that behaves like an app: it can be installed to the home screen, work partly offline and load quickly on repeat visits. It is a cost-effective middle ground between a website and a native app, though some device features are more limited, especially on iOS.

Websites are usually slow because of oversized images, too many third-party scripts, heavy themes or plugins, slow hosting and missing caching. A performance audit measures each of these on real pages. At Quoryx.AI we fix the biggest causes first and re-measure Core Web Vitals to prove the improvement.

Schema markup is structured data added to a page that tells search engines exactly what the content is, such as an organisation, product, article or FAQ. It does not guarantee higher rankings, but it can make pages eligible for rich results and helps search engines and AI tools interpret content correctly.

Make a website accessible by following the Web Content Accessibility Guidelines (WCAG): sufficient colour contrast, full keyboard navigation, text alternatives for images, clear labels on forms and correct heading structure. Automated tools catch some issues, but testing with a keyboard and screen reader is essential. Accessibility also improves usability and SEO.

A redesign does not have to hurt SEO if existing URLs, content and metadata are carried over or redirected properly. Most ranking drops come from missing 301 redirects, deleted pages and changed content. Map every old URL before launch and monitor Search Console closely for several weeks afterwards.

AI answer engines tend to cite pages that give clear, direct, well-structured answers from sources they can crawl and trust. Publish specific answers to real customer questions, use structured data, keep facts consistent across the web and make sure AI crawlers are not blocked. Quoryx.AI builds sites with this answer-first structure.

Off-the-shelf software is better when your process is standard and a product already fits well, because it is quicker and cheaper to start. Custom software is better when your workflow is a competitive advantage, several tools need joining up, or subscription and workaround costs keep growing.

Choose a software development company by checking relevant past work, how clearly they explain their process and how they handle scope, ownership and communication. Speak to the people who would actually build your product. Quoryx.AI lets clients interview proposed team members before the work starts.

Outsourcing suits businesses that need a complete team quickly, specialist skills or a defined project, while in-house developers suit companies whose core product is software and needs constant work. Many use both: an agency builds the first version and the in-house team takes over or grows alongside it.

Ask who owns the code and accounts, how requirements are agreed, how often you will see working software, who you will speak to day to day and how scope changes are priced. Also ask what happens after launch and how you could move the work to another team.

The main risks of outsourcing are unclear requirements, poor communication, hidden quality problems and being locked in to a supplier who controls the code. Reduce them with a written specification, regular demos, code in your own repositories and a contract that assigns intellectual property to you.

Onshore development uses a team in your own country, nearshore uses a team in a nearby country with similar working hours and offshore uses a team further away. The right choice depends on budget, communication needs and skills. Quoryx.AI has offices in London and Lahore and works with businesses worldwide.

A software development contract should cover scope, deliverables and acceptance criteria, payment terms, ownership of intellectual property, confidentiality, data protection, warranty and support, and how changes and termination work. It should also confirm that code, accounts and documentation are handed over to you.

Red flags include quoting a fixed price without understanding the requirements, refusing to put code in your repositories, vague answers about who will do the work and no regular demos. Pressure to sign quickly and no clear change process are also warning signs of trouble later in the project.

It can be, if you use business or API versions whose terms exclude training on your data and you control what information is shared. Consumer accounts may have different data terms, so check the settings. For sensitive work, models can run inside your own cloud account with access controls and logging.

GDPR applies if your software processes personal data of people in the EU, and UK GDPR applies to people in the UK, wherever your business is based. It requires a lawful basis, data minimisation, security and respect for user rights such as access and deletion. Building these in from the start is far easier than retrofitting them.

The EU AI Act regulates AI systems placed on the market or used in the EU according to risk: some practices are banned, high-risk uses carry strict obligations and systems such as chatbots have transparency duties. Most business AI falls into lower-risk categories. Quoryx.AI builds with these requirements in mind and works with your legal advisers.

HIPAA applies to US healthcare providers, health plans and their business associates handling protected health information. A compliant app needs access controls, encryption, audit logs, secure hosting under a business associate agreement and documented policies. At Quoryx.AI we build with HIPAA requirements in mind and work with your compliance advisers.

PCI DSS is the security standard for any business that accepts, processes or stores payment card data. Using a payment provider's hosted checkout or embedded fields keeps card numbers off your servers, which greatly reduces your compliance scope, though you still complete an annual self-assessment with your provider.

SOC 2 is a US-originated audit report on how a company's controls protect customer data, while ISO 27001 is an international certification for an information security management system. Both show buyers that security is managed seriously. Software can be built to support either, but the audit or certification itself is carried out by an independent body.

A penetration test is an authorised, simulated attack in which security specialists try to find and exploit weaknesses in your application or infrastructure. Most businesses test at least once a year and after major changes, and some customers or regulations require it. Findings are prioritised and fixed, then retested.

Encryption in transit protects data as it moves between devices and servers, usually with HTTPS and TLS, while encryption at rest protects data stored in databases, files and backups. Both are standard for business software, and sensitive fields such as identity numbers can be encrypted individually for extra protection.

Prompt injection is an attack where hidden or malicious instructions in user input, a web page or a document trick an AI system into ignoring its rules or leaking data. Defences include limiting what the AI can access, treating external content as untrusted, filtering outputs and requiring human approval for sensitive actions.

A business application should have automated, encrypted backups stored separately from the live system, plus a tested plan for restoring service after an outage. Agree how much data you could afford to lose and how long you could be offline, then design around those targets. A backup that has never been restored is not proven.