Questions beforewe build

We start from the business goal, users, workflow, data, technical constraints, and operational complexity. A website is usually enough when the goal is presentation or conversion. An app, AI system, Web3 product, or custom system only makes sense when the workflow needs deeper interaction, automation, ownership logic, or long-term operational structure.

We will say that early. Some ideas are better reduced into a smaller MVP, split into phases, validated manually first, or solved with a simpler system before custom development makes sense.

Yes. A rough idea can be turned into scope through discovery, requirement shaping, flow mapping, and technical direction. The goal is to define what should be built, what should wait, and what should not be built yet.

No. We may decline or reshape a request if the deadline is unrealistic, the scope is unclear, the legal risk is too high, the expected outcome is not technically reasonable, or the required capacity is not available.

Yes. Budget discussions use IDR unless a project-specific agreement states otherwise. The contact form budget field is an estimate, not the final project price.

Budget helps us shape a realistic scope before the first discussion. It is not used to maximize price; it prevents a mismatch between expected features, quality level, timeline, and available investment.

The form budget is only an early signal. Final estimates depend on features, integrations, user roles, content readiness, third-party costs, timeline pressure, technical unknowns, and the delivery model.

Cost usually increases when the project includes custom business logic, many user roles, admin dashboards, third-party integrations, app store release work, blockchain complexity, AI data pipelines, strict security needs, or an urgent timeline.

Yes. Starting with an MVP is often the better decision when the product has many assumptions. We define the smallest useful version first, then phase the rest after the first release or validation.

Prepare business goals, references, brand assets, content, existing system access, technical documents if available, and the people who can approve decisions. Missing materials do not block discussion, but they can affect timeline and scope clarity.

We can still start discovery, but missing copy, images, or brand assets need to be handled deliberately. They may become part of the scope, be supplied later by your team, or use temporary placeholders until final materials are ready.

Small refinements can be treated as revisions. Changes that alter structure, logic, features, integrations, platform targets, or business direction are scope changes and may affect cost and timeline.

The timeline can move. Projects depend on feedback, materials, access, and approvals from both sides. If required inputs are late, the schedule may shift without being treated as an agency-side delay.

We review the intended behavior, dependencies, available APIs, platform limits, security needs, and implementation complexity. If uncertainty remains, we may recommend a prototype or technical spike before committing to a full build.

Third-party integrations depend on API access, documentation quality, account approval, rate limits, pricing, uptime, and policy changes. We can integrate them, but we cannot control external provider behavior.

Yes, after an audit. Existing code quality, documentation, access, architecture, dependencies, and security risks determine whether it is better to continue, refactor, isolate, or rebuild.

We disclose it early and either adjust scope, move it into a later phase, or recommend specialist support. Hidden complexity is more expensive than a clear boundary.

Use a CMS when non-technical users need to update pages or content regularly. Use an admin dashboard when the system needs to manage data, users, workflows, transactions, or operational records. Static content does not always need either.

Default SEO usually covers clean structure, metadata basics, semantic markup, performance-aware implementation, responsive behavior, and indexable pages. It does not automatically include long-form content strategy, backlink campaigns, or ongoing SEO management.

It depends on the proposal. We can help set up domain, hosting, analytics, and form email, but the client should own critical accounts and credentials whenever possible.

Sometimes. If the current codebase is stable and flexible, redesign can be layered on top. If the foundation is fragile, outdated, or difficult to maintain, rebuilding may be faster and safer.

Performance is considered through image handling, responsive layout, bundle awareness, animation choices, loading behavior, and basic pre-launch checks. Heavy integrations, hosting quality, and third-party scripts can still affect final speed.

The platform choice depends on audience, device usage, budget, release urgency, and feature requirements. Android-first can make sense for Indonesia-heavy audiences, while both platforms may be needed for broader consumer products.

It can, but offline behavior must be designed intentionally. Offline support affects data sync, conflict handling, local storage, security, and user feedback when the connection returns.

A client-server app needs a backend, API contract, authentication model, database structure, and deployment environment. If those do not exist yet, they become part of the project scope.

The client should own app store accounts. We can help prepare builds and submission assets when included, but store approval depends on Apple or Google policies and review timelines.

Device features need permission design, fallback states, real-device testing, and platform-specific behavior checks. They are not just UI features; they affect reliability and release readiness.

Not always. Blockchain is useful when ownership, transparency, decentralized execution, or trust-minimized records are core to the product. If a normal database solves the problem better, we will say so.

Critical ownership or transaction logic may belong on-chain. Private data, frequently changing content, heavy files, analytics, and operational workflows usually stay off-chain for cost, privacy, and flexibility.

Formal third-party audits are not included by default. We can write tests and review contract behavior, but independent security audits require separate scope, time, and budget.

Gas fees, wallet costs, RPC providers, storage services, marketplace fees, and protocol costs are usually external costs. They should be planned separately from design and development fees.

Deployed contracts can be difficult or impossible to change depending on architecture. Risks include contract bugs, key management, wallet UX issues, network fees, protocol changes, and user mistakes.

Not always, but useful AI depends on useful context. If data is missing, messy, or not trusted, the first phase may need to focus on data preparation, knowledge structure, or workflow mapping.

We reduce risk with scoped use cases, curated context, retrieval design, prompt behavior, fallback rules, evaluation examples, and human handoff where needed. AI output still needs clear boundaries.

The system should admit uncertainty, ask for clarification, route to a human, or return a safe fallback. Pretending to know is usually worse than a controlled non-answer.

Yes, if access, permissions, storage, and privacy boundaries are designed properly. Sensitive data should be limited to what the AI actually needs and protected through the right infrastructure choices.

We define success around operational value: time saved, fewer repetitive tasks, faster response, better retrieval accuracy, clearer handoff, or measurable improvement in a workflow. AI should be judged by usefulness, not novelty.

It depends on the delivery model in the proposal. If source code is included, it is handed over after payment obligations are complete. If the project is managed by FrontierLayer, access may be handled differently.

Ownership follows the agreed delivery model and is transferred according to the proposal or agreement after payment is completed. Third-party libraries, assets, and services keep their own licenses.

The client should control core business accounts such as domain, hosting, app store, cloud provider, analytics, payment gateway, and API provider accounts where possible. Shared access can be granted for implementation.

Yes, when included in scope. Handover can include access notes, deployment notes, environment variable guidance, admin instructions, or technical documentation depending on the project type.

Support can be arranged after launch as a separate maintenance scope. It can include bug checks, minor updates, monitoring support, content updates, or ongoing product improvements.

Bug-fix warranty covers technical issues caused by our work within the agreed warranty window. It does not cover new features, changed requirements, third-party outages, client-side modifications, or issues caused by external providers.