Questions people ask before working with us
Straight answers about scope, pricing, ownership, support, and the parts of a project that usually go unsaid until they cause trouble.
General
+What kind of work do you take on?
Infrastructure that must stay online, software that carries daily operations, and games from prototype to playable build. If a project touches two of those three layers, it is usually a good fit for us.
+Is there a minimum project size?
No fixed minimum. Small, well-defined pieces of work are often the best way to start — they let both sides learn how the other operates before anything large is committed.
+Can you take over a system someone else built?
Yes. We start with a read-only audit: architecture, dependencies, access, and the risks nobody wrote down. You get that write-up whether or not you continue with us.
Process
+How do projects usually start?
A short discovery conversation, then a written scope with milestones, owners, and an explicit list of what is out of scope. Nothing is built before both sides agree on that document.
+How often will we hear from you?
Working increments at the end of each cycle plus a short written summary. We prefer a reviewable build over a status presentation.
+What if the requirements change mid-project?
They usually do. Changes are handled as scope adjustments with a clear effect on time and cost, agreed before anything moves.
Commercial
+How is work priced?
Fixed scope for well-defined deliverables, monthly retainers for ongoing operations and support. Both are quoted after discovery, never before.
+Who owns the resulting code?
You do. Ownership of project-specific source and assets transfers on final payment. Reusable internal tooling stays ours, licensed to you for the delivered system.
+What happens when the engagement ends?
A handover package: documentation, credentials, runbooks, and a walkthrough session with whoever takes over.
Support & operations
+Do you offer ongoing support?
Yes — support tiers range from business-hours response to continuous monitoring with defined escalation paths and response windows.
+How do you handle security?
Least-privilege access, secrets kept out of source, dependency review before release, and logging that makes an incident reconstructable afterwards.
+What about backups and recovery?
Every system we operate has a documented restore procedure that is tested, not assumed. A backup nobody has restored is not a backup.
Have a project in mind?
Tell us what you are building or what keeps breaking. We reply with an honest read on scope, sequencing, and whether we are the right team for it.