FAQ
Questions, Answered Plainly.
No. Describe what you want people to accomplish, what is painful today, and what absolutely needs to work. The intake explains unfamiliar terms where practical, and “Not Sure” is a useful answer. SBG translates the project goal into technical requirements during scoping.
SBG reviews fit first. If the request is a potential match, the next steps are a defined scope and proposal, separate legal acceptance, the applicable payment/readiness steps, authorized work and stage reviews, final verification, and handoff. Submitting an intake does not create a contract, charge you, or authorize work.
Yes. If you already know the likely Build package, choose it from the Build, Pricing, or Compare Build Packages page. That selection stays with the intake as your requested package. It does not force the project into a bad fit: SBG still checks the published boundary before a proposal, agreement, payment, or authorized work.
Yes. SBG can support adult personal, family, or household software projects when they fit the service boundary. Personal use is not a disqualifier. The project’s primary use is resolved before proposal/legal acceptance where required so the correct signing identity, disclosures, and any non-waivable consumer protections can apply. The service is not directed to children.
Essential, Launch, and Business use two 50 / 50 stages. The first 50% authorizes Stage 1. The second 50% does not become eligible until Stage 1 is completed, presented for your review, and explicitly accepted by you. Accepting Stage 1 is not another contract signature and does not automatically charge the second 50%.
The exact deliverables depend on the accepted scope, but SBG’s goal is a clean handoff rather than permanent dependency. Completed custom deliverables and source-release obligations follow the accepted agreement, with relevant release/version information preserved. Where practical, production resources intended to belong to you should be client-controlled or transferred to client-controlled accounts.
No. Your app is not our billboard, and we’re not planting a tiny flag in the footer like we conquered it. We don’t operate that way. SBG does not require a ‘Built by SBG’ footer, badge, watermark, backlink, co-branding mark, or other customer-facing SBG attribution. You paid for your product; it should present itself under your brand—not ours. SBG’s name can still appear where it legitimately belongs in private project records, handoff evidence, support records, or signed documents. Any notice independently required by a third-party or open-source license is also separate. Neither is an excuse for us to turn your app into an SBG advertisement.
No. SBG is not limited to one development platform. SBG builds responsive web applications, and the specific tooling is selected to fit the approved scope, security needs, integrations, and handoff requirements rather than forcing every project into the same stack.
SBG uses AI-assisted tools throughout development, analysis, debugging, review, and testing. Those tools can accelerate the work, but they do not get to declare their own output correct. SBG remains responsible for reviewing and verifying the work within the approved scope.
Atelier is one focused responsive web app with one primary purpose, one primary user type, and one compact workflow. It is a real working product with a verified source release, a documented handoff, and a 30-day window to report possible qualifying defects in SBG-delivered original-scope work. A timely qualifying case can continue after the reporting window closes. Atelier is not a discounted customer portal, multi-role platform, payment system, integration project, or native App Store app.
Yes. SBG Build services are responsive web applications that can be used in a modern phone browser and, where supported, added to the Home Screen. Native iOS or Android App Store development is not offered as an SBG Build service.
For work that fits its boundaries, yes. Essential is intentionally limited — one primary user type, up to three workflows, roughly five screens. If the project exceeds Essential’s boundaries, we’ll recommend the appropriate package instead of stretching Essential beyond its scope.
No. Audit is independent and read-only wherever reasonably possible. Repair is a separate, scoped engagement. Unless an SOW expressly says otherwise, the $495 Audit is not a penetration test, regulatory/compliance certification, or legal opinion. Its included defect-support window applies to material defects in SBG's Audit/report deliverable—not repair of defects the Audit discovers in your app. We'll never quietly fold one into the other.
Maintenance is available only for an eligible project SBG previously completed and handed off. It is an optional annual service with four documented reviews, no automatic renewal, and a defined minor corrective/compatibility boundary. It is not unlimited tickets, feature development, redesign, emergency/SLA support, or a promise that every reported concern is an included repair. It is additional to the applicable 30-day post-completion defect-reporting window. If SBG did not build or complete the app, start with Audit or Rescue instead.
No raw project credentials through ordinary SBG channels. Passwords, MFA/recovery codes, private keys, access tokens, and secret API keys stay out of intake, email, portal messages, project notes, and source ZIPs. When access is required, we prefer official collaborator, team, temporary-account, provider-delegation, or other least-privilege methods. If a platform genuinely requires a raw shared secret and offers no safe delegated method, SBG may be unable to perform that access-dependent work rather than asking you to send the secret unsafely.
Source code is proprietary and deserves a more controlled trip than an ordinary email attachment. When an authorized Audit, Rescue, or eligible Maintenance engagement genuinely requires a source ZIP, the authenticated Client Portal opens the exact project-specific Secure Source Upload. That keeps the transfer tied to the correct client and project and preserves the transfer record. An intake, account, or preliminary conversation is not permission to send source. Repository, platform, test, or staging access is handled separately when that is the safer or more appropriate method. If required source cannot use the approved transfer process, SBG may be unable to perform that work.
We'll talk about adjusting optional scope or the date — never verification. Faster isn't always finished, and verification is never the schedule buffer.
No. Software delivery does not guarantee revenue, SEO rankings, investors, customer acquisition, or commercial success. We deliver the agreed software and document what was verified, what was not verified, and any known limitations. Business results depend on factors beyond the software itself.
Absolutely. Modern AI tools have made software development remarkably accessible. If you have the time and interest, go for it — and come back to us for an audit or rescue when you're ready. Annual Maintenance is available only for eligible projects SBG previously completed and handed off; outside apps start with Audit or Rescue.