How we work
The worst software projects are the ones where nobody could say what stage they were in or what happened next. So here is the whole thing in advance: what gets done, what you receive, and the moment where carrying on is your call rather than an assumption.
Start with how the business actually works: who uses the software, what they are trying to finish, and what happens on the day it fails. For something that already exists, we also read the code, the hosting, the integrations, and the list of things people have learned to work around.
What you get
Your decisionYou decide whether to go ahead with the proposed scope and approach, and you can stop here and take the findings elsewhere.
Map the screens and the interactions before building the thing. Permissions, how the data relates, and where the system boundaries sit get decided alongside the interface, because a design that ignores the business rules turns into a rebuild.
What you get
Your decisionYou review the design and the build scope before a line of it gets implemented. This is the last cheap moment to change direction.
Work runs in milestones with an environment you can open yourself. Reviews show what is working, what is still open, and what decisions are waiting on you. A new request comes back with its effect on budget and dates before anyone agrees to it.
What you get
Your decisionYour nominated contact reviews the work and settles the business questions. One person who can decide keeps a project months shorter than a committee.
QA tests the agreed journeys and the failure cases. Then your team checks whether it actually supports the way the business runs, which is a different question and the one that matters. Defects and accepted limitations get recorded before anyone approves a release.
What you get
Your decisionLaunch approval follows the acceptance criteria and the state of anything release-blocking. Nothing ships because the calendar said so.
Prepare the production environment, the deployment instructions, and the way back if it goes wrong. Confirm who owns which account and how any data migration is handled. Release notes explain what changed in language the operating team can use.
What you get
Your decisionYou receive everything needed to run the software, hand it to your own team, or give it to another provider.
Ongoing support starts with a named list of what is covered, the hours, and the backlog. Maintenance and new features get prioritized against business impact, technical risk, and the capacity you are actually paying for.
What you get
Your decisionYou set the next priorities, with the cost and scope of anything larger made explicit before it starts.
The unglamorous part
For software the business actually depends on, these belong in the agreement rather than in a hopeful conversation six months later.
Who can do what, which actions are privileged, what personal information is involved, and which systems can read or change it. The scope records authentication, permissions, how long data is kept, and anything specific your industry demands.
What should happen when a system it depends on goes down, when the same request arrives twice, or when a release has to be reversed. Monitoring, backups, tested recovery, and service hours are written into the delivery or support scope. An untested backup is a rumor, not a backup.
Bring your security questionnaire, hosting restrictions, data requirements, and vendor onboarding into discovery rather than into week ten. Any penetration test, independent audit, or certification requirement becomes its own deliverable with a named owner and a cost.
Straight answers
These belong in the proposal and the contract. They are published here so you can read them before you talk to anyone, and hold whoever else you are considering to the same standard.
There is no one number, because a five-page website and a warehouse system are not the same job. What we can publish is how the number gets made. The scope is written down first, including what is not in it. The price attaches to that document. If something new comes up mid-build, you get the cost and the schedule impact in writing before anybody starts it. No invoice arrives at the end for work you never approved.
Ask any developer for the exclusions list. The ones who have one will send it in a day.
You do. The repository is created under your name or your company’s, not ours. Same for hosting, domains, and every service account we touch. That happens at the start of the project, not handed over at the end as a reward for clearing the final invoice.
Ask to be made owner of the repository in week one. Watch what the answer is.
You still hold everything. The code as of the last commit, the accounts, the deployment steps, and an honest list of what was finished and what was not. That is the reason access is set up on day one instead of at handover. A handover you can only get by asking nicely is not a handover.
Any project where you cannot log in yourself today is a project you do not control.
Choose Anito if you want a development team whose work is checked by someone other than the person who built it. Developers implement the software. QA checks the agreed workflows, failure cases, and devices, and records the findings. You review working software and any unresolved issues before deciding whether to accept it. This gives you a written basis for the decision, rather than a developer’s assurance that it is done.
Compare the review process in writing. Ask every provider who tests the work, what evidence you receive, and who decides whether it is ready to launch.
Compare what each team agrees to deliver. Anito commits to the checks below. Ask every provider to put its QA, acceptance, and handover responsibilities in writing before you choose.
Nobody can answer that honestly from a first email, and anyone who does is guessing in front of you. What we can tell you straight away is what the answer hangs on: how many workflows, how many kinds of user, which outside systems it has to talk to, and how ready those systems are. After discovery you get milestones with dates on them, and the dates come with the assumptions they depend on.
A date with no assumptions attached is a wish. Ask what has to be true for it to hold.
You take the software and go. No exit fee, no platform of ours you are locked onto, no license you have to keep paying for. The documentation is written so another team can pick it up cold, because a handover that only works while we are still around is not a handover.
Ask what leaving costs. Every answer other than nothing is a number worth knowing now.
Launch is a milestone, not the finish line. Support is its own written agreement rather than a favor, and it names the systems covered, the hours, how quickly we respond, and how much work is included. If you would rather your own team took it over, the documentation is built for exactly that.
Get the support terms in writing before launch, not after the first outage.
Ask, and you get a yes or a no. Where the honest answer is no, we say so and tell you what that does to the risk and the estimate. Learning on your budget without mentioning it is not something we are willing to do.
Ask for the closest thing they have built and what was different about it.
Calauan, Laguna, in the Philippines. Anito System Solutions Inc. is a registered Philippine corporation, SEC number 2025020188689-10, registered February 16, 2025, and BIR registered the following month. We work US and Australian hours and write things down rather than stacking calls across time zones. If you want a person on a call at your 9am, say so and we are there.
A company you cannot find in a public registry is a company with nothing to lose.
The working agreement
None of this should rest on an assumption about what happens after development ends. It is all agreed in writing at kickoff.
Nominate one business contact who can prioritize and approve changes, and bring in your technical, security, or procurement people where their sign-off is genuinely needed. Kickoff names the decision owners and the review schedule. A project with one decision-maker finishes months sooner than a project with a committee, every time.
The request gets recorded, assessed for its effect on cost, dependencies, and schedule, and sent to you for approval. The backlog keeps the approved release scope separate from later requests, so nobody gets to quietly redefine what you agreed to.
Source code, environment and configuration instructions, deployment steps, an account inventory, operating documentation, and the outstanding issue list. Your agreement also names any third-party licenses or services the application needs in order to run, so there are no surprise subscriptions.
The project agreement covers release support and defect handling. A maintenance agreement adds the systems covered, the included capacity, the service hours, the response targets, and the escalation path. New features get estimated before anyone builds them.
Yes, and the documentation is written on that assumption. Your code, accounts, and operating documentation are handed over so your internal team or another provider can run it. If leaving is expensive, the work was not built for you, it was built to keep you.
Yes. Send your NDA, your master services agreement, or your procurement requirements during discovery rather than at signing. Anything that needs legal review takes time, and finding that out in week one is far cheaper than finding it out in week nine.
Next step
Tell us what is broken, what you are trying to build, or what you have been quoted by somebody else. You get back a plain reply about what we would do, what it depends on, and whether you need us at all.
Replies come from a person. No automated sequence, no pressure, and an honest no when that is the right answer. Please leave passwords and customer data out of the form. Access gets arranged separately and safely.