If you're still considering how to build a backoffice, management page, or management interface for your startup or new business venture, or whether to outsource it, read "4 Things to Know Before Outsourcing Your Backoffice Development".
I'll skip the ice-breaking discussion about the necessity and importance of backoffice systems. As the title suggests, this article will provide a brief checklist or playbook for when you're outsourcing development.
Who Should Read This
- Those unsure about what to prepare for outsourcing contracts
- Those unsure about which vendor to choose and what kind of contract to make
- Those unsure about additional considerations specific to backoffice outsourcing
4 Essential Elements for Successful Backoffice Development Outsourcing
- Detailed Development Requirements Specification
- Selecting a Good Outsourcing Vendor
- Contract Terms That Must Be Agreed Upon
- Thorough Communication Verification
Detailed Development Requirements Specification
Writing requirements specifications is the beginning and end of the contract.
It's about clearly defining what pages you need, what functionality you require, and who should have access to what information from where.
To be direct, there's no perfect way to write requirements specifications, and it's challenging to write them perfectly.
I've seen specifications that included business models and competitive differentiators, and others with UX flowcharts. Sometimes, despite all this detail, they missed mentioning that all data was in spreadsheets and needed to be migrated to a new database!
If you search for requirements specification templates, you'll find many options. Choose the template that seems most appropriate for your needs.
Requirements specifications are used to help outsourcing vendors understand and commit to the backoffice they need to build. While the specifications are ultimately completed through meetings with vendors, not preparing them in advance can make it difficult to compare quotes between vendors and may lead to overlooking important elements.
The most crucial aspect is not missing any essential functions and pages. Here's a tip: get reviews from actual users. If you don't have actual users or it's unclear, imagine a hypothetical user and think through what buttons they'd click and what pages they'd navigate to, from login until they resolve various situations.
Once you've written everything, seek advice or self-reflect.
"How much would it cost if we built this ourselves?" or "What additional features might we need later? How much would it cost to outsource those additions?"
As mentioned in "4 Things to Know Before Outsourcing Your Backoffice Development", the best way to develop a backoffice is in-house. You need someone who maintains your company's context and can respond most actively when urgent or major issues arise.
If you've still decided to outsource, the next step is finding a 'good outsourcing vendor.'
Selecting a Good Outsourcing Vendor
Generally, finding something good means looking for the most famous or expensive option. However, such vendors in the outsourcing field are either extremely expensive or focus on large projects from major corporations.
The next approach is comparing and selecting, but there are several things to keep in mind.
- Not every outsourcing vendor can build every type of backoffice well.
They might only be capable of web or app development, or be unfamiliar with certain development stacks/infrastructure/external service integrations. There are specific vendors suitable for the backoffice you want to build. - Look for vendors with development experience, portfolios, and track record.
Developer experience, accurate schedule/cost estimation, number of backoffice systems handled, problem-solving ability, contract reliability, maintenance contract options - contracting with experienced vendors is essential. It's too late when deadlines slip due to estimation errors and lack of capability, or when you contact them for additional features/maintenance only to find they've closed down. - Always compare before choosing. After choosing, compare again.
Given the significant cost and time investment, you can't compare too much. If they have portfolios, check them; if they have reputation, verify it. After selecting several vendors this way, meet with them, get quotes, and compare again.
Choosing a good outsourcing vendor is like buying good seafood.
While promotional photos and reputation matter, you need to verify the actual product and reviews, and get detailed quotes for various conditions through direct meetings.
One more tip: it's better if the outsourcing vendor's portfolio or customer base includes cases similar to your project/backoffice. They might have already solved potential problems and can provide better advice about requirements.
Contract Terms That Must Be Agreed Upon
There are many conditions to verify when contracting.
Cost, schedule, page and function specifications, maintenance, security, scope of defects, person in charge, compensation for delivery delays, additional cost charges, payment methods and schedules, confidentiality obligations, intellectual property rights for deliverables - there are countless conditions.
In most cases, smooth contract execution prevents problems, but there are conditions that must be agreed upon in advance or are likely to cause issues: costs and schedules for additional requirements, and maintenance.
Costs and Schedules for Additional Requirements
How appropriately costs and schedules are agreed upon is surprisingly not a major issue. While you've probably agreed appropriately if you compared and chose carefully, issues that arise during development are larger, more frequent, and more sensitive.
Most problems arise from additional requirements during or after development. Specifically, the costs and schedules for these requirements become issues. Whether something was overlooked, assumed too obvious to mention, or discovered necessary later - additional requirements arise with almost 100% certainty.
Vendors handle small matters themselves, but when facing large requirements, they must choose one of three options: request additional costs, request schedule delays, or absorb unexpected losses. And when additional costs and schedules appear, differences in opinion often emerge.
Therefore, first write good requirements specifications to minimize such issues, then secure some additional budget and schedule for contingencies. It's also good to agree in advance on how to handle such situations.
Maintenance
Both management and adding new features are best handled by the original developers.
Not only does it take extra time for others to understand the data structure and flow, backoffice page structure, and code, but the original developers are best equipped to respond definitively when defects occur.
Therefore, it's good to include maintenance and additional implementation conditions in the contract or confirm and verbally agree on them in advance. While you can contract separately whenever issues or requirements arise, this might not always be possible.
You might have chosen them for their low cost only to discover they're students/recent graduates (a surprisingly frequent case) who can't provide timely maintenance, or they might have closed down. They might demand much stricter conditions than the initial contract, or respond much more slowly to additional requirements than during the initial contract.
That's why, as mentioned in selecting good outsourcing vendors, you should check portfolios, track record, and reputation rather than just looking for the cheapest vendor.
Thorough Communication Verification
Modern outsourcing communication typically occurs through SMS like KakaoTalk, chat services (Slack, Discord), phone calls, and email.
Given the nature of outsourcing where multiple projects are handled simultaneously, these communication channels are often unified into one or two. It's good to check these channels in advance or verify if other channels can be used before contracting.
You should also confirm what response time they guarantee through these channels. You need to verify how feedback on deliverables, maintenance, and problem resolution will be handled.
While projects with short development schedules of about two weeks aren't usually problematic, for longer schedules, clients should continuously check intermediate deliverables. Requirements might not be accurately conveyed through brief specifications and meetings, leading to incorrect development, or the overall schedule might be delayed more than expected.
Checklist
- Detailed Development Requirements Specification
- Are all necessary functions and pages for the backoffice listed?
- Have you imagined actual usage flows and verified nothing is missing?
- Selecting a Good Outsourcing Vendor
- Have you chosen an experienced vendor with a portfolio?
- Have you checked and compared multiple vendors?
- Contract Terms That Must Be Agreed Upon
- Have you agreed on how to handle additional requirements?
- Have you discussed how maintenance will be handled after development?
- Thorough Communication Verification
- Have you confirmed how communication will occur and when responses are possible?
- For large projects, have you established methods for intermediate inspections?
Conclusion
There are many other considerations: guarantees for assigned personnel, security management of customer data in the backoffice, ownership of development deliverables, inspection of completed development, handling schedule delays due to external factors (delays might be forced by review/contract schedules of payment PG companies or mobile apps), infrastructure expansion as users increase, and more.
I've written about what I consider the 4 most important elements needed for successful backoffice development outsourcing. For successful outsourcing, not only the vendor but also the client must prepare and understand. After all, the client is the one who will use and pay for it.
Prepare well and choose well.
