Questions to settle before the project takes shape

What kinds of work can Faith Forge Labs help with?

The services include websites, product experiences, online commerce, customer workspaces, internal tools, integrations, mobile applications, workflow automation, content and ongoing care. The appropriate combination depends on the task. A clear product comparison may solve a public-information problem without requiring accounts or a new database.

Do you work with an existing system?

Yes. We first examine the relevant source, configuration, provider dependencies and ordinary maintenance task. A supported adjustment may be sufficient. If the required behaviour is outside the existing system's capabilities, the investigation should explain that limitation before a replacement is proposed. Care and takeover covers this assessment.

Can Hebrew and Arabic be included?

They can be included in an agreed content and implementation scope. Identify who supplies or approves each language, which journeys are covered and how later changes are reviewed. Direction, mixed-script values and external provider screens also matter. Discussion and documentation languages, translation assistance and review responsibilities are agreed for the project.

Are the Hebrew and Arabic pages exact translations?

They cover the organisation and services through their own useful emphases. Some Arabic pages focus on comparing products and selecting a manageable first project; Hebrew planning also examines document review and operational handoffs. Follow the language-labelled links for the relevant material. The current inquiry form and individual service details are in English.

Who decides whether a product claim is correct?

The product owner or other authorised client reviewer. We can organise the evidence, build the publishing workflow and identify where a claim appears, but technical implementation does not establish commercial or professional truth. An unresolved capability should remain a question rather than become a reassuring answer invented for the page.

Can a payment connection be included?

Potentially, after reviewing the chosen provider, merchant account and supported operations. The merchant and provider establish eligibility and commercial arrangements. Development scope should distinguish order creation, provider responses, reconciliation and any separately authorised financial operation. No provider acceptance or regulatory result is guaranteed by a website proposal.

Does a portal need to be part of the first release?

Only if the recurring private task justifies it. A public comparison and a well-defined inquiry may be enough for an initial decision. A customer workspace introduces users, organisation relationships, permissions and ongoing ownership. Those are useful when needed, but they should be explicit work rather than a decorative addition.

How are cost and timing established?

Through the agreed outcome, pages, data, connections, review and handover. Existing content quality and outside dependencies can change the work substantially. The scope page explains what to compare between proposals; it does not publish a universal package price or delivery period.

What happens after release?

The handover identifies maintenance tasks, accounts and known limits. Ongoing support, response arrangements and further development require defined terms. A completed build does not automatically provide continuous monitoring or unlimited changes. See support planning for the questions to resolve.

What should we send first?

A short description of the person, obstacle and intended result, with a public page or safe fictional example if useful. Use the decision kit to prepare, then contact us. Keep credentials and private records out of the first message.