It's hard to see who the customers would be. Using an API requires an atypical level of technical expertise. Contractors have their suppliers. Suppliers have their inventory. Architects? well maybe since specifying high priced unavailable materials is not unknown...but their business is the least likely to make money by spending money on an API.
In general, money in construction changes hands when construction happens or materials are sold. Monetizing information about stone is perhaps more likely the more it is directly tied to such transactions.
Good luck.
>> In general, money in construction changes hands when construction happens or materials are sold. Monetizing information about stone is perhaps more likely the more it is directly tied to such transactions.
This is useful, and hadn't thought about it like that. Tying it to specific stones (as there is a lot of variation even in the same lines), and to the sale.
This is not something that I've seen a market for, but every natural stone company has its own internal database. We have one, and this is a effort to make it accessible.
Thanks.
That said, I don't spend hours chasing down specific granites so that might be value alone to others.
Have you discussed pricing with potential customers? They are in the best position to suggest the price.
I expect you could have a few plans starting out at $99, $249 and $499.
Tiers by users/api calls, etc.
Construction industry software typically seems to command a premium price so maybe more that my off the cuff numbers.
Pricing is more art than science, how much will companies pay you based on their time savings/value of using the api is the answer. Also you ran roll out initial introductory pricing and then change based on what the response/signups are.
You said no one else is doing it, but where ever you got the idea from, how much are they charging?
We have our own, constantly-updating stone database, so the line of thinking was that we'd just externalize that.