Third-Party Developers
Here is information to help you have a productive experience with a third-party developer.
- Are you set up to work with a third-party developer?
-
- Do you have a MinistryPlatform sandbox? This means having a copy of the application and database that you or a third party like Higher Ground Technologies periodically refresh.
- Is your sandbox set up so that you would give a third-party developer root-level access to the server so they can work in SQL Server Management Studio? Depending on where you put the test application and database, this may mean the developer is working on your production servers.
- Where will the test application be deployed? Will the developer deploy and test the app on your servers? It is generally tested on their servers, which requires the sandbox is open to them and generally means it is available from outside your network over port 443 (SSL/https).
- Who will deploy the finished app into production? This may require root-level access to your SQL and IIS servers. If the developer was working in an isolated sandbox, you have to have a plan for deployments.
- Who is your third-party developer?
-
- Do they already know how to work with MinistryPlatform API? Share this article and our API with the third party before they make your quote.
- What software language do they work with? Pursue a developer who already works with the MinistryPlatform REST API to help this third party get through the initial learning curve. In most cases, we will not train third-party developers since we are not staffed to work with developers at various levels of expertise who may program in other languages.
- Do they have experience with SQL Server databases? If they don't, they can't build an app by themselves. It takes knowledge of SQL Server to extend MinistryPlatform and write queries for any project.
- Do you trust them to have complete access to all of your data even if the application only has a small subset of your data in scope? Access to the API and root-level access to the SQL Server means they may be able to access more data than just the subset of your data that the application will ultimately use.
- Will you provide them with a user account to the MinistryPlatform application so they can visually inspect the pages and understand how data is laid out? Many developers ask for a data dictionary. That can be provided, but it's better for them to see the system from the application which faithfully reflects how data is structured.
- What do you expect your third-party developer to do?
-
- Will they provide a storyboard that visually describes what the finished app will do? ACS Technologies can review the storyboard as a Professional Service.
- Will they write stored procedures in the MinistryPlatform database to extract data over the API? If no, who will? All apps require dedicated, new, unique stored procedures to query data over the API. ACS Technologies can write these as a Professional Service.
- Will they write insert and update statements against the API? They will need to know the schema of the tables and pages they are working against. This is a requirement if their app needs to change data in MinistryPlatform.
- Will this application require the creation of new pages, the creation of sub-pages, or the addition of new fields to existing pages? If yes, who will extend the MinistryPlatform database schema and wire that up into the MinistryPlatform application? ACS Technologies can do this as a Professional Service.
- What projects are likely to succeed?
- Projects are likely to succeed when an experienced developer has appropriate access to the system, works in consultation with ACS Technologies, and has a reasonable goal to achieve. Generally, both parties have to anticipate working together on multiple projects to offset the effort involved in the initial setup and learning curve.
- What credentials should I provide developers?
- See Giving Developers Access.