A seller of mineral rights has a peculiar problem. The asset cannot be photographed on a kitchen counter. Its value depends on documents, geography, production and the revenue it might yield. A buyer needs enough of that information to make a decision. Somewhere between the two sits a listing form, which must turn an awkward bundle of evidence into something another person can understand.
This is where Clavax becomes interesting. The software company’s work for Energy Domain, a Texas marketplace for mineral and royalty interests, involved precisely that conversion. The brief extended from uploading documents to evaluating an asset and arranging a transaction. A marketplace needs an inviting entrance, certainly. It also needs somewhere sensible to put the paperwork.
- Clavax builds custom web, mobile and enterprise software for businesses.
- Its transaction work includes real estate auctions and mineral-rights marketplaces.
- It also promotes specialist platforms including BidHom and Novus Loyalty.
- The practical lesson: define the data and decision rules before choosing the technology.
01 / A deal is a sequence of decisions
Energy Domain’s project makes a good lens because the business problem is so concrete. Sellers wanted to market mineral and royalty interests; buyers wanted data with which to judge them. Clavax’s case study describes a web and mobile platform combining listings with revenue information, analytics and alerts. Selling options included an auction, a buy-now route and a negotiated deal.
Consider the listing itself. In the workflow Clavax describes, a seller uploads checks, conveyance documents and leases. The platform associates revenue data with wells and maps the tracts. That is a considerably more demanding job than asking for a title, a price and a photograph. The listing has to make a complicated asset legible.
Then come the rules. An auction needs a starting bid, bid increments, a reserve price and a start and end date. A negotiated deal needs a way for the buyer to make an offer and for the seller to accept, reject or counter it. Each choice changes what the next screen should permit. The interface is the visible expression of the business’s policy.
- 01UploadChecks, leases, conveyances
- 02ConnectRevenue, wells, mapped tracts
- 03ChooseAuction, buy now, negotiation
- 04TransactBids, offers, counteroffers
The detail I like best is less imposing: save progress. The case study calls for sellers to pause an unfinished listing and return later, including keeping several drafts at once. It is a modest concession to ordinary life. People get interrupted. Documents are missing. A useful application remembers where they stopped.
02 / The first obstacle was understanding the job
Clavax’s account of Energy Domain begins its challenges with clarity of requirements. The team had to decide who the users were, how information should appear at different stages and what experience to provide. It also says the online energy-listing concept was new to the team. Domain knowledge had to be acquired alongside the software work.
Large datasets created another pressure. Clavax describes maintaining speed while handling information from different organizations. It says it avoided an overly complex technology stack to reduce later problems and support scalability. The listed tools include Django, Python, React, PostgreSQL and AWS. Those names tell us what was used; the more useful decision was to let the workload guide the selection.
COVID restrictions made planning and explanation harder by limiting face-to-face interaction. The team relied on virtual meetings and online discussion. Clavax reports delivering within the planned interval. That is the company’s account of its own work, and the informative part is the sequence of difficulties it records: understanding, data, performance, security and coordination.
“Time and cost estimations are totally dependent on nature of the App and client’s business requirements.”Deepak Tomar, founder interview published by Clavax, 2016
03 / The same problem wears different clothes
Clavax began in 2011, with Auction.com among the early clients named in its history. Its auction case study describes work spanning account creation, registration and real-time bidding, with asset management and contract automation among the solution areas. The underlying problem is recognizable: a transaction must move through defined stages without losing its participants or its information.
Other clients broaden the picture. Kemgo’s brief involved a B2B platform for buying and selling chemicals. Jabil’s case study concerns multilingual web content and keeping that content accurate as it changes, using Episerver. These are businesses with different customers, but both need software to organize information that keeps moving.
Fujitsu offers a particularly useful distinction. Clavax’s case study concerns a frontend and API service for the Digital Annealer Global Commercial Service, using AWS and connecting to an existing backend at Equinix. The work included user management and API-token management. Access to sophisticated technology is itself an engineering assignment; the underlying computing system belonged to Fujitsu.
Testing is another part of that assignment. For the healthcare messaging application IM Your Doc, Clavax describes an audit addressing security, performance and compliance-related requirements. Its approach combined automated and manual testing. The customer needed confidence in how the application behaved, beyond confidence in how it looked.
Clavax’s position on that year’s list. A dated growth marker, rather than a promise about the next project.
04 / When a project becomes a product
Clavax’s business has two visible routes. One is commissioned engineering: a customer brings a requirement and pays for a system, its integration and subsequent support. The other is a specialist product offering that lets more than one customer use a similar foundation. Its website presents BidHom, Novus Loyalty and Claymable alongside its services.
BidHom gives the auction experience a recognizable product form. Its current website combines real estate websites with listing, offer, auction and transaction management. It markets plans for different requirements, including enterprise arrangements. For a brokerage, the attraction is having related activities in one platform instead of commissioning every piece separately.

Novus Loyalty addresses a different recurring workflow: rewarding customers and encouraging return visits. Clavax describes it as a SaaS and enterprise loyalty offering. Its own product website discusses rewards, referrals and connections with business systems. A loyalty point looks tiny from the customer’s side. Behind it are eligibility rules, transaction records and a decision about what it can buy.
Claymable extends the product menu into medical-insurance administration. Clavax’s homepage presents it as AI-powered software for profile and policy management and claims processing. Together, these offerings suggest a firm trying to package experience around particular business processes. That is an interpretation of the portfolio, rather than a claim that every service engagement becomes a product.
05 / Buy the fit, budget for the life
Where does Clavax fit? Between a company’s internal engineering team, other development consultancies and packaged business software. Its breadth is useful when a project combines an application, a content system, cloud infrastructure and testing. Its more distinctive evidence is the transaction work: rules and data that have to survive the journey from a customer’s intention to a completed action.
There is a sensible purchasing test here. A standard workflow may already have a satisfactory product. Bespoke development becomes more compelling when the business has unusual data, approval steps or integration requirements. Even then, the buyer needs people who can explain those requirements and decide between competing priorities. Hiring a developer does not remove that responsibility.
Tomar’s scope-dependent approach to estimating is a useful starting point for the money conversation. A buyer should define the initial release, the systems it must connect to, testing expectations and the support required after launch. The build budget and the operating budget belong in the same discussion. Every new data source and exception can become work someone must maintain.
The lesson a reader can copy is practical. Map one transaction from beginning to end. Mark the documents, decisions, interruptions and handoffs. Decide what happens when a bid misses the reserve or a seller leaves halfway through a form. Choose technology after that exercise. Clavax’s Energy Domain work shows how much of a software project is contained in those apparently small questions. The deal may end with a click. Making that click useful takes rather more thought.
Keep exploring
Clavax website · Explore BidHom · Explore Novus Loyalty