Here is information to help you have a productive experience with a 3rd party developer.

Are you setup to work with a 3rd Party Developer?

• Do you have a MinistryPlatform sandbox? This means having a copy of the application and database that is periodically refreshed by you or a 3rd party like Higher Ground Technologies.
• Is your sandbox setup so that you would give a 3rd 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 3rd Party Developer?

• Do they already know how to work with MinistryPlatform API? Share this article and our API with the 3rd 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 3rd party get through the initial learning curve. In most cases, we will not train 3rd 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 MP and write queries for any project.
• Do you trust them to have complete access to all of your data even if the application will only have 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 3rd Party Developer to do?

• Will they provide a storyboard that visually describes what the finished app will do? Think Ministry 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. Think Ministry 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/pages they are working against. This is a requirement if their app needs to change data in MP.
• 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 MP application? Think Ministry 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 Think Ministry, and has a reasonable goal to achieve. Generally, both parties have to anticipate working together on multiple projects in order to offset the effort involved in the initial setup and learning curve.

What Credentials should I provide Developers?

See Giving Developers Access