
Ask HN: Got my first enterprise customer...now what? - throwthisawaypl
Built my first app with Django, Postgres w&#x2F; Amazon S3. Have had a free option, a couple paid options ($5&#x2F;mo, $9&#x2F;mo), and an &quot;Enterprise please contact&quot; option. It&#x27;s done well and paid the server costs and given me some profit, which is really cool.<p>But as I mentioned, this is my first app. Had a small corp contact me and they would like me to run an instance of this as a private thing. Essentially either on their servers or (I guess?) from my servers, but from their domain name. It&#x27;s like an internal around the office tool.<p>The Enterprise option was kind of a lark so I didn&#x27;t expect this.<p>Can anyone point me in the right direction from the tech or pricing side? Not sure if it would just be me installing the Django app inside their intranet, or if it would be a SaaS thing from me. Really no clue. I tried to stick with Django best practices for portable apps as this was my first time working with the framework, so theoretically with the right settings it should work anywhere.<p>Sorry if this is overbroad, trying to not give too much away.
======
taprun
It's hard to give specific pricing advice without any information about your
product, customer, competition or goals.

Try to figure out how much benefit the company thinks it would derive from
your product. That's the absolute ceiling of what you can charge. If the
company can earn an extra $1,000 by using it, it's not going to pay $5,000.

Now think how much the company is currently spending to deal with the problem
(labor costs, software licenses, etc). This _might_ be a good estimate of the
floor for how much you can charge.

It's hard to say without more information, but you'll probably want to think
about pricing somewhere in between the ceiling and the floor.

The lower your price, the higher the ROI you can demonstrate and the more
likely the sale (usually). Of course, if you price too low, it can make you
look non-credible and scuttle a deal. I mean, whom would you rather trust, a
neurosurgeon that charges $40,000 per operation or one who charges for $8 per
operation?

Unfortunately, I suspect that you've anchored your prices low with the free,
$5 and $9 tiers. As such, they'll probably balk at a high price for the app.

You'll need to break your customer's mindset and get him to understand that
this new version is delivering a _lot_ more value than your existing plans.

Better yet, you might want to see what you can do to look like you're not even
selling something that's at all like your other plans.

Focus on selling more than just the software. Support, updates and guarantees
are all things that people pay for.

One key piece of advice I have is to think this through. Supporting one unique
customer with a unique product version might cost you a lot more (in terms of
time and aggravation) than it is worth. Think about how likely you are to sell
similar "private things" to other firms (and what other benefits you might
receive from this specific sale) before you decide that it's worth selling in
the first place.

BTW, here's a book I wrote about pricing software:
[http://taprun.com/pricing/](http://taprun.com/pricing/)

------
sound_of_basker
Tech: deploy as a VM. For starters, allow the client to configure the VM
network interface before downloading it. (On the fly, mount the VM with qemu
nbd or whatever and write to the image, unmount qemu-nbd and proceed with the
download request)

Expose everything as a RESTful API in the VM. NOTHING ELSE. Don't spend too
much time hardening your VM security wise. Have a strict release schedule.
Listen to the customer on what features they might want. But have your release
schedule. Don't blindly add in everything this client wants.

If client is insistent on source code, throw an escrow clause into your
contract. Dont had over everything yet.

Sales: draw up a contract. charge according to the sales figures of the client
(yearly or one time is left to you). I cannot stress this enough.

------
codegeek
Charge them a Yearly license (non-refundable) if they want to host in their
own environment. Also add a surcharge for intranet/internal hosting. The
reason is that it may be a bit more work for you to offer it within their own
servers/environment vs your own hosted SAAS.

I will break it down into the following:

1\. Charge a Yearly License upfront

2\. Add a surcharge for one time installation

3\. Come up with an SLA and get it agreed in writing

4\. Offer a separate paid "professional services" for customizations,
enhancements or other requests from client.

------
dorfuss
A general remark: A year ago, working at one of the The Big Four companies, I
was taught one important lesson:

"Great disruption" \- in short: business has to be prepared that within a year
or two there will be 10 new global competitors, selling the same or better
product for a better price. In order to survive you have to provide excellent
customer service and support, automate your internal processes to lower the
margin costs, focus on comoditization of services (that is: people love Coke,
it's cheap, you open it with your finger, you drink, you go - this is how we
want to use insurance, mortgages, cars and credit cards and municipal
administration), compete by improving quality not by lowering price, carefully
listen to your clinet, do a lot of personal tailoring.

Ask for recommendations.

------
boulos
You should look at WordPress VIP, GitHub for Enterprise, etc. as a guideline.
I would caution you against doing an on-prem installation, as you'll have to
learn the ins and outs of their organization, deal with their server setup
("Oh, you used Ubuntu? We use RHEL 5, is that a problem?") and would need to
find some alternative to S3 for your backing data.

And as others will no doubt point out: charge a lot more. In some cases,
Enterprise pricing is more like a Veblen Good
([https://en.wikipedia.org/wiki/Veblen_good](https://en.wikipedia.org/wiki/Veblen_good))
if you only charged say $25/month they would realize that your thing is junk,
but the same thing for $250/month sounds very desirable.

------
saluki
Run it like a SaaS duplicate your current setup for their ip, they'll probably
use something like yourapp.theirdomain.com.

Keep control of the server and your code just provide it to them as a private
version of your SaaS app.

I would price this at your current hosting costs x 2 + $200/mo to cover setup,
added maint. + profit.

Note/Build in possible data/bandwidth useage increases as they scale up usage
in their contract or terms of service.

If you're using stripe maybe setup a few bandwidth tiers above a base one
you're setting them up on with private instance pricing. You can add this to a
private instance pricing page too this might be popular.

congrats/good luck.

------
zhte415
Setting up inside even a similar-but-not-the-same environment is horrible. My
experience: dependent packages the need to be compiled on their environment,
undocumented network lags form internal servers/services, lack of sysadmin
competency.

Perhaps an option, to keep this as a SaaS, is to offer a DNS mapping to your
own server (give them access to, if they need root/admin access, seems so),
but it is your environment set up as you need.

Pricing: Depends on what you're doing. Jumping from $9 to $10000s which is
what this sounds like sounds a big step. Re-write pricing on a per-user per-
month / per-usage instance perhaps? As they're enterprise, that's where your
growth is: scale.

------
nibs
I am going through this right now. What I did was price it monthly, ask for
annual payment up front, and charge more.

I am charging $100/month for a drop-in enterprise tool for SME businesses.
Don't forget to charge for services too. So the initial invoice is $1-2k and
then $100/month.

It is somewhat annoying to setup the whole app inside their intranet, so you
may need to research code mangling tools (protect your IP somewhat) and
installing deps on their server, but otherwise just charge a lot more and
provide service.

------
partisan
Exciting... I don't know what you should do as I haven't hit that stage yet,
but can you let us know what you ended up doing?

------
zer00eyz
First of all congratulations.

Second, this is a HARD problem, pricing at this level is never easy to figure
out.

>But as I mentioned, this is my first app. Had a small corp contact me and
they would like me to run an instance of this as a private thing. Essentially
either on their servers or (I guess?) from my servers, but from their domain
name. It's like an internal around the office tool.

Take a look at this:
[https://github.com/pricing/plans](https://github.com/pricing/plans) and then
this [https://basecamp.com/3/pricing](https://basecamp.com/3/pricing)

Both have "enterprise options" that are close in price, but are very different
things, and for different reasons.

Githubs enterprise version is effectively a "self hosted white label" \--- if
you love github and want to use it, but work for an organization like a bank
that wants (needs) to have control that 2500 buck option is the ONLY thing
that fits the bill.

On the other hand, base camp has three clear tiers... The only reason your
going for that enterprise account is because your a LARGE organization, with
lots of data or one that needs an SLA (cause your international? or deeply
dependent on the product)... white label isn't even an option. This also means
that a company might not be able to use basecamp due to compliance/legal
issues.

Having looked at these, this request is going to fall into one of three camps.

\-- There is a legal reason they want it in house. \-- There is a business
reason they want it in house (aka can they use your tool with clients) \--
They are fishing for a discount. 100 people is still a "small" company, can
you see them getting $10,000 worth of value out of it?

Some of these answers may be apparent to you, some may not. Do put your sales
guy hat on, and ASK QUESTIONS of this potential client

\-- Anticipated number of users? \-- Is it a hard requirement that you host
this on your own infrastructure (for legal or other reasons)? \-- As well as
running this under your own domain, do you need it co-braded, or fully white
label? \-- Do you need invoiced billing, is there a preference for annual
(with discount) or monthly billing?

With answers to the above in hand you should be able to make an informed guess
about what the intent is. Fully white label, needed for clients, legal
reasons, are going to be the "enterprise options" that cost lots of money.
Your going to end up with a contract that spells EVERYTHING out, including
some very high rates for support, and possibly a monthly fee for on call
services that are "use it or loose it"

You may figure out that they are looking to SAVE money. If this is the case
then its a fairly good deal for you provided you structure the agreement
right. A large check today, might mean that you get to move to a reserved, pre
paid instance if your using EC2, and you can pass through your s3 costs to
them if they pass a certain threshold, bill them for the first terabyte, and
tell them that each additional costs 10$ a month rounded UP.

This is also where you have to be careful. If your on a net 30 (you get paid
30 days after you submit an invoice) and then rack up a 20k s3 bill will you
be able to cover it out of pocket till you get paid by them? Figure out your
fixed costs, figure out your variable costs, break them out, mark them up and
pass them along. Bill for everything else is the best option for YOU.

Lastly, Don't be afraid to say NO. Sometimes walking away from a deal is a
bargaining chip, but don't take an offer, or offer something up that doesn't
make you money.

