Categories
All Consulting CTO/CIO

How not to handle “we’re not paying” emails…

via GIPHY

I saw this thread recently posted on Hacker News. “We’re not paying invoices due to the pandemic” – How to handle these.

Join 35,000 others and follow Sean Hull on twitter @hullsean.

What shocked me is what Patrick McKenzie (@patio11) suggested:

“The right response is probably ‘I have received your letter. The invoice is good. I demand payment by the date on the invoice, under the terms of our contract'”

Wow. Powerful words. Mildly threatenting.

Here’s what I would suggest…

1. I demand payment under the terms of our agreement

I really don’t want to ever receive letter demanding anything. It’s unpleasant. It feels threatening. Why would you send such a missive to your client or customer?

As a consultant or freelancer, you should understand that you are *NOT* an employee. As such you are not protected by the law in the way payroll employees are. You should understand that the first ones who get paid are payroll, next would be rent & utilities, and lastly would be contractors or vendors.

What’s a better alternative. First keep good communication. Let your client know we are all struggling, and we can work through this together.

I typically send a message with subject “a gentle reminder: invoice xyz due on date abc”. Encourage any kind of communication, and keep it open. Don’t be afraid to remind your customer again in two weeks. If you don’t hear back, ask again just to make sure the messages are getting through.

Patience wins the day.

Read: How to avoid legal problems in consulting?

2. I’ve got bills to pay, this is serious

Talking from your own point of view, is not helpful. What’s more it encourages your customer to also see things from a selfish vantage point. Instead speak from their point of view. Explain that you understand where they are coming from, and let’s work together to get a portion of the bill paid. 50%, 25%, 10%. Any amount is good because it means an action has been taken. It confirms the invoice is valid.

As far as those bills go. If you’re a freelancer, and running out of money, you’re doing it wrong. When you freelance there is overhead, for health insurance, vacation & sick leave etc. If you are not making the rates that cover these costs, it doesn’t make sense to be freelance in the first place. In fact it means you’re not billing right, packaging right and selling right.

Related: When clients don’t pay

3. Remember this is a test for everyone

The current pandemic is a challenge for everyone. Small and large businesses, freelancers, deli, laundry owners, restaurants & music venues. I can go one. Please keep this in mind before you go off and send some email to your non-paying client, that you will later regret.

Keep your perspective, take a deep breath, and be the bigger man. Take the high road, and keep your center. We will all get through this together.

Related: Why do people leave consulting?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Categories
All Cloud Computing CTO/CIO

Why is there a company whose only purpose is to help me with my AWS bill?

via GIPHY

I know everyone is talking about the pandemic at the moment, I thought I would sidestep the topic, and continue to discuss what I know best. Which is public cloud!

Join 35,000 others and follow Sean Hull on twitter @hullsean.

Of late, I see more and more discussions on CTO forums, and in the news on surprise AWS bills. Did you hear what happened NASA’s cloud deployment fail?

So I thought I’d provide some history, and a few ideas…

1. Oracle days

Believe it or not this has happened before. In the days when I did a lot of Oracle work, I remember it was terrible how tough their licensing was. And companies were pretty much hamstrung because they needed the technology to run their business.

Given the demand, new firms like Miro Consulting stepped in to help. Their business is specifically built to help customers with out-of-control Oracle bills.

Read: How to hire a developer that doesn’t suck

2. Repeating refrain

What’s this got to do with Amazon Web Services you say?

Just today I discovered a firm that promises to help you lower your aws bill by 20-40%.

Promises aside, if there is a business doing this, there must be money to be made in it. So that speaks to a sizeable market opportunity.

Related: When you have to take the fall

3. AWS has a webinar on the topic

Hey if you’re thinking you can manage it yourself, why not look to AWS for assistance on lowering your bill.

Something tells me there’s a conflict of interest there, but I digress.

Point is with this topic becoming of growing interest, I think you’ll see more businesses stepping into this niche.

Related: How do I migrate my skills to the cloud?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Categories
All Consulting CTO/CIO Devops Startups

I’m building a startup. What should I watch out for?

via GIPHY

I’ve worked with close to 200 startups over the years. So I’ve seen a lot of stuff. Some of the get-rich-quick managed to get broke even quicker. And others saw great engineers leave behind a clunky maze of an architecture with little or no documtation.

Join 35,000 others and follow Sean Hull on twitter @hullsean.

Here are some thoughts on what to be mindful of…

1. Keep the stack simple

Are you asking yourself questions like these:

o if we build x,y,z it will save us time later
o we need kubernetes because everyone is using it
o let’s deploy on Amazon’s Cloud, everyone is there

If so you may have sidestepped keeping the stack simple. If you are building a proof of concept, mvp, chances are you do not need to build all the bells and whistles.

Relentlessly apply the discipline to keep things simple.

Read: Are pioneers and process people different breeds?

2. Use boring technology

You may be tempted to use some exotic new language. I know this new framework solves all the problems that have come before. No!

Let someone else live on the bleeding edge. I’m not suggesting to use COBOL, though there is still a surprising amount of that still around. What I’m saying is 5 year old tech is *not* legacy.

Not sure? Do a quick search on a job site for the language or technology. How many candidates do you get? If they are rarer you will pay more. And replacing your genius developer will be even harder.

But boring technology is not just about finding talent. It means many of the problems have already been solved. This is huge. There are proven ways to implement with the tried and true.

Related: Why is Martin Weiner special?

3. Beware of sharks in the water

Sharks can come in many forms. Investors that want to take 50%, a google or an Amazon that could rearchitect your solution in a week. These are real and present dangers.

Let’s not forget overspending on co-working spaces, and hidden costs around benefits, and surprising fees on your data or aws bill.

Related: How can 1% of something equal nothing?

4. Outsourcing – trust but verify

You may be able to hire one or two devs locally in new york, but if you need a larger team, you’ll likely look to outsourcing. There are tons of talented and brilliant engineers worldwide. So it makes sense to leverage this.

Beware though of handing all control to a team outside our shores. That’s because if you stumble into a legal trouble, you cannot use legal methods to resolve them. Some examples…

o what if you lost your aws keys and the outsource team holds you hostage?
o what if you are hacked, and the outsource team abandons the project?
o what if the outsource team tries to steal your IP?

I’m not suggesting here that outsource teams are any more likely to do these things than some firm locally. I think these events are rare in business. But if they happen local you can use the levers of the justice system to resolve. Remote may not lend to that.

Related: The art of resistance – when you have to be the bad guy

5. Relentlessly manage time

Your time is going to be short, and you’re trying to do the impossible. Use the tech wisely:

o use monitoring systems to alert you – no need to manually check things
o beware of slack and email – as they can destroy productivity
o automate where you can see real benefits
o keep the architecture simple!
o network for hiring people

Related: Is maintenance a forgotten art?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Categories
All Cloud Computing Cloud Migrations Consulting CTO/CIO

What can we learn from NASA’s AWS fail?

via GIPHY

I was just reading the Register, which is sort of the UK’s version of Slashdot, and they had a jaw dropping title. NASA moved 247 petabytes into AWS and then later learned about EGRESS costs

OMG! Face palm. Wow.

Join 35,000 others and follow Sean Hull on twitter @hullsean.

To say this is a disaster is an understatement. Could it have been prevented? Not likely by 100% strategic thinking. I believe a certain amount of real-world testing & prototyping is the only way.

Here are my thoughts…

1. Expect hidden costs

Everytime I check there are more AWS services. Just now I did some googling, and the number stands at 170. Not only is it tough to keep up with all of those, but the offerings are constantly evolving, getting new features and so forth. That means the pricing and costs are evolving too.

All this means an infinitely complex web of interconnecting pieces, so it is near impossible to predict prices in advance. The solution? Prototype.

And this would have helped save NASA. Because you would build, feature test and load test too. In all of that would have come a small estimate of cost which would include EGRESS costs.

There are no guarantees in this game, but it is surely getting complicated.

Read: How can 1% of something equal nothing?

2. Vendor lock-in is not dead

With the receding of some of the big old world vendors like Oracle, many have forgotten the shark like tactics they used with startup companies.

The model was something like this. Send in the big guns, nicely dressed to get you on board. Finesse the sale. Offer deep discounts, and get the customer on Oracle. After a year, maybe too, start squeezing. You’d be surprised how much blood comes out of diamonds.

These days we feel more free to port our applications to different cloud vendors. Even if mostly everybody is on Amazon already. But this NASA story really highlights the great organizational cost to migrate to the cloud. You architect your application, you do cost planning, and so on. So once you’re there, it’s hard to unravel.

Related: Is Fred Wilson right about dealing in an honest, direct and transparent way?

3. New possible hacking vector

Since costs are tied to usage in the public cloud, this could have implications for hacking. If a bad actor wants to cause you harm, then can now just use your service more.

Don’t like company A? Write some bots to access them from obscure locations, and ramp up those egress costs. With all the complexity of the cloud, are most firms monitoring for this sort of thing? I don’t see it in my engagements.

Something similar happened to me. I wrote: when mailchimp fraudulently charged my credit card. It really happened. Do I think it was intentional? You’ll have to read the article to get my 360 degree take on it.

Related: What mistakes did you make when starting as a consultant?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Categories
All CTO/CIO Startups

Are pioneers & process people different breeds?

via GIPHY

I was just reading Oliver Eidel’s blog. He had a great post, with some provocative ideas. Pioneers versus Process people.

Join 35,000 others and follow Sean Hull on twitter @hullsean.

Now since I love to play devils advocate, after reading this thought provoking article, I thought I would write a bit of my take.

1. Are pioneers and process really characteristics of two different people?

As Oliver describes it, there are two completely different humans. Are they different breeds? Different species perhaps? Whatever the case, he argues that people either have one characteristic or the other.

To me the pioneer, is the engineering expression of creativity. They want to create new things, run with an idea, and see if they can make something happen. But even the most stodgy people have a bit of creativity in them, even if they don’t always express it. Yes I believe everyone has a tiny pioneer buried inside.

And so too, the pioneer, can should the need arise, buckle down and get tasks done. Yes they can be disciplined too, if you want to apply a different word.

Read: How can 1% of something equal nothing?

2. Do pioneer stage startups need more discipline?

I’ve worked at many a startup. I love them. Riding skateboards to work, and having dogs around the office is certainly a laid back downtown atmosphere, that appeals a lot more that the financial district buttoned up scene.

Also pioneer startups, often have a lot of leeway, to, as Oliver says “walking off in random directions, developing other great products”. This is how new ideas are hatched.

That said, many of these startups will one day fail. And it’s not for lack of idea, or market need. It’s often team related. That’s right, some of the best and coolest startups fail for lack of discipline. They’re too pioneering!

Related: Is Fred Wilson right about dealing in an honest, direct and transparent way?

3. Do process stage companies need more pioneering spirit?

I’ve also worked at quite a few larger, somewhat stodgy firms. These are so process heavy, that simple things can take forever. Everything requires a signoff. Deploying code can take weeks. Yes indeed they do things the old fashioned way, and that’s because they always have done that.

Could they use a pioneer or two to shake things up? Totally! Creative energy, drive and spirit could help them find faster ways to do things, and become unstuck when their old school process mentality is limiting their growth.

Related: What mistakes did you make when starting as a consultant?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Categories
All Cloud Computing CTO/CIO Devops

When should I use Ansible versus packer or Terraform?

via GIPHY

I was having a conversation with a colleague recently. We wee discussing devops, and the topic of Ansible came up as I was advocating it as a great too to get things done.

Join 35,000 others and follow Sean Hull on twitter @hullsean.

Here’s what he had to say…

— quote —
I’ve tried using ansible a few times and this is what I found with it.

It is great for what it does. It’s wonderful to be able to spin up a new app or web server automatically. However what I have found for my needs is …

It is easier to build a piece of furniture than it is to explain all the steps required for someone else to build it. Or in order to replicated the steps automatically.

With cloud servers, it’s enough, for me that I’ve built it once. When I need to spin up another, I simply clone the working copy.

— unquote —

My thoughts below.

1. When is Terraform good

Terraform is a coss-platform infrastructure building tool. If you need an IAM user or S3 bucket, Terraform can create it. Need an ec2 instance of a particular type, deployed with an autoscaling group TF is a great tool for that.

With Terraform you can capture in code, everything about your application stack, so that you can standup a complete copy in another region, that’s powerful!

Read: How can 1% of something equal nothing?

2. When is packer right?

Packer is another useful tool that Devops can use to automate. Like AWS own EC2 Image Builder, it allows you to create the images that you boot your instances off of. Think of them as docker images for the server itself.

For example there are lots of dependencies your application requires, and you’ll install with your package manager. And there are services you want to start. You *could* use an ansible playbook to get these going, but better to build a new image that contains all the software you need on the box.

Packer easily sits into your CI pipeline, so you can have new software deployed and ready anytime.

The principal difference is that a new AMI requires you to spinup a new server. You can’t take action on a running server with this tool.

Related: Is Fred Wilson right about dealing in an honest, direct and transparent way?

3. When does Ansible make sense?

In particular here’s what my response was about Ansible itself.

— quote —

Absolutely. It’s an interesting balance to strike.

Because of course packer or EC2 image builder are very powerful and fit neatly into a CI pipeline. That said there are things ansible is nicely suited for too.

For example I want to distribute public keys onto specific servers. I have a yml file with the keys. I have a new developer starting, I have him or her git checkout branch, edit keys.yml, commit, push changes, then make a pull request. When the new keys.yml file gets merged, an ansible playbook kicks off to distribute the new set of keys to the relavant servers.

— unquote —

If you want to take actions on running servers, like deploying keys or other ongoing tweaks, that is where Ansible really shines.

Related: What mistakes did you make when starting as a consultant?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Categories
All Consulting CTO/CIO Devops Hiring

Should I join this new startup Delicious Data?

via GIPHY

I’ve been asked this before by folks.

Hey, you know technology, what stock picks would you recommend?

Join 35,000 others and follow Sean Hull on twitter @hullsean.

It’s a tough question, with a lot of intangibles. It’s no wonder people ask friends for advice. You have to think about what matters to you? Your free time? Your income? Your time to commute? What about the team you’re working with? Or what your job contributes to the world?

Many of those I can’t quantify for you. What you can quantify money, so it’s worth doing that!

1. What are their prospects for success?

When asked about the chances of a companies success, knowing the industry may be one small part. You also have to know how many competitors they have, and where they are along in the process. And it’s not just developing technology, but team dynamics that are huge. From what I hear VCs hire more for team than for idea.

What factors outside domain expertise come into play? Lots! The weather, financial markets, or the big guys like google or amazon coming into the market. They may not buy you, they may just replicate your idea. Then where are you?

Read: How to hack job search the smart way

2. How can I apply mathematics to money?

My answer is always the same, go for the S&P 500. If the S&P beats 90% of all stocks, then nine out of ten times you will win this way. That’s it, calculation done.

Yeah but how does that pertain to joining a startup?

How indeed. I still say invest in the index, not in one pony. So use that advice as you will.

Gambling on one company is something for gamblers. If you want to become a vc, that’s a different question. In that case you would do a lot of due diligence on team and idea, to be sure you’re putting your money in a smart place.

Can’t I do that as an employee? Yes sure, but the intangibles remain strong.

How can 1% of something equal nothing?.

Related: Is Fred Wilson right about dealing in an honest, direct and transparent way?

3. How does all this help me?

It leaves out the intangibles. Don’t count paper as part of your compensation package. If money is a key factor, divide the number of hours per year by your salary plus real benefits – health insurance and so forth – to come up with a real number. Compare that to other jobs.

The heck with these finance jobs that pay $200k and offer a $50k bonus, but ask you to work 90-100 hours per week. Why not get two $180k/yr jobs at 45 hours per week? You see the logic right?

And what else? Of course if you’re going to be commuting in to an office everyday, and joining the family, you want to have great coworkers. So make sure you like the place where you’re working. I don’t know how much this is worth to you, but I would say it’s quite valuable!

Related: What to do when prospects mislead you?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Categories
All Consulting CTO/CIO Devops Software Development

Do you fear you are an imposter? Join the club

via GIPHY

I was reading another delicious hacker news thread, this time on a psychology question. How do you work with the fear of your own incompetence?

Join 35,000 others and follow Sean Hull on twitter @hullsean.

It’s a great question. I’ve had this suspicion for years, and it was only after stumbling on psychology books that I even knew it was a thing.

So how *do* you manage this fear?

1. Demonstrate that it is a fear

Fear is a funny thing. It can color reality. You may not even realize it’s happening. When it comes to imposter syndrome, prove yourself wrong. Do the work, and then step back and show yourself the evidence.

You’re a logical rational engineer, so you should be able to weigh the evidence, and see that you made a mistake.

Doing good work is not about perfectionism. It is about knowing you can execute, and delivering quality. That doesn’t not mean there are no imperfections. That means good enough. That means equal to or better than the team you’re working in.

That means you’re improving the bottom line for the firm you’re part of. Help them deliver new features, new code, new product. And help other team members do the same. That’s the name of the game.

Read: How can 1% of something equal nothing?

2. Look at your history

Whenever I have this feeling, I look at my own history. Then it makes me sorta chuckle. I have a list of twenty companies that I worked for recently, and they’ve all been really happy with my work.

How do I know I did good work? They paid me handsomely, paid me on time, and then recommended me to other colleagues.

That’s how I know I’m not an imposter. Am I perfect? Nope. Do I know everything? Nope? But I do good work, and I take ownership, admit when I’m wrong, and play well with others.

If you want to stand out, take a look at these two pieces:

Check out: What do the best engineers do better?

And this: How to think like a senior engineer

Those will help you on your way…

Related: Is Fred Wilson right about dealing in an honest, direct and transparent way?

3. Realize your perfectionism

I think a lot of engineers or bright people have this problem. They want everything to be perfect. They want to produce documents without spelling errors, and code without bugs. They want to deliver everything on time perfectly every time. And they want to feel they know everything.

But it doesn’t play to your benefit. People resent this type of thinking, and it’s unhealthy besides. Take a deep breath, realize we’re all working towards the same goal, and keep your eye on the ball. That means have a sense of humor. You’re probably *way* harder on yourself then others will ever be.

Related: What mistakes did you make when starting as a consultant?

4. Be easier on yourself and easier on others

As you begin to be “easier” on yourself, hopefully you’ll also be a little bit easier on others. Be patient with mistakes. Understand that people have a lot going on in their life. Notice that they are trying.

Sure even after you gain a sense of humor, there will be some people who are not trying, who don’t care or who are really incompetent. But have your default position be patience, and give them and yourself the benefit of the doubt.

Usually if said person is really that bad, others will also complain and the problem will come to management’s attention. It is their job, after all to manage the team as a whole, and keep it productive.

Have fun!

Related: Why did mailchimp fraudulently charge my credit card?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Categories
All Consulting CTO/CIO Security

How do we secure an existing aws hosted application?

via GIPHY

What if you don’t have the luxury of a greenfield. You are looking at an already built application, and asking yourself, how do I secure this?

Join 35,000 others and follow Sean Hull on twitter @hullsean.

One can think of it as a giant labyrinth, with many turns and many paths. Some of those paths have not had light shining in them for some time. So you’ll need to be cautious, thorough, and vigilant.

Here are some notes on where to start.

1. Scanning – code

One area you’ll need to dig into is the application code itself. If you don’t have the luxury to push new code, you’ll need to verify what version is deployed, and scan the repository for keys or passwords. You can also scan on the server itself. Better to double your efforts.

Read: What do the best engineers do better?

2. Scanning – network

Your VPC is obviously your first layer of defense. Scan the routing table policies, to make sure there aren’t open ports or whitelisted IPs.

Do the same sort of review for security groups, as those are an alternative method for configuring access to servers.

AWS has a service called Flowlogs, which can be enabled. These give you detailed network layer logging, which you can then scan for trouble.

Related: Is Fred Wilson right about dealing in an honest, direct and transparent way?

3. Scanning – IAM, keys & console

Your existing devs probably have keys to some or all of the EC2 boxes. If you don’t want to relaunch all of these boxes with new keys, or don’t have the luxury to do that, you’ll need to lock down the security groups, whitelisted IPs and VPC routing rules.

You’ll also need to carefully review IAM roles & policies. Amazon Inspector may be a useful tool to scan your environment, and find glaring holes and enforce best practices. But you’ll also want to do your own scanning both automated and manually eyeballing the accounts.

You’ll also want to lock down console access, especially the root account, and any others that have adminstrator privileges. Enable password policies and password rotation, as well as multi-factor authentication. There is also a nice toggle for “alert on login”. You certainly want to know about those!

Related: What mistakes did you make when starting as a consultant?

4. Scanning – services

Review all of the AWS services that are deployed. Ask yourself some of these questions:

o which regions & availability zones am I deployed in?
o what elastic IPs do I have configured where?
o what IAM roles & policies do I have created?
o what databases, API gateways & S3 buckets are configured
o etc…

Cloudtrail can be a great help here as it can log all sorts of useful information. You can then scan those logs for problems.

Related: Why did mailchimp fraudulently charge my credit card?

5. Rebuilding

The scanning approach can work, but there is a strong need to be thorough. If you miss one whitelisted IP or existing ssh key, you can leave the whole network open to a crafty intruder.

Another option is to rebuild the whole application. This gives you the time to:

o automate the whole stack with terraform
o test that everything is working
o plan for failover
o ensure that every bucket is secure with lifecycle policies enabled
o ensure that every EBS volume is encrypted
o enabled cloudtrail, cloudwatch etc

o potentially setup in a *brand new* aws account, for even more confidence
o backup all the pieces of the application as you go

Read: Did Disney+ have to fail?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Categories
All Consulting CTO/CIO Devops Startups

What do the best engineers do better?

via GIPHY

I’m fascinated by this topic.

I recently found another thread on HN about it What do top engineers you know do that others don’t.

Join 35,000 others and follow Sean Hull on twitter @hullsean.

As always for hacker news, there’s a feisty debate about what such character includes.

Here’s my take.

1. Tackle learning quickly

Whether it means getting up to speed on a new service that AWS has launched, building a new api for an application that has never been built before, or getting up to speed with a new platform. Learning is ongoing.

Top engineers can make this a seemless part of their daily routine. Getting going quickly with new concepts and technologies, means wading into the water at first, to gain the general lay of the land. Now you can talk intelligently about the features, limitations and challenges.

From there he or she can dive in quickly to the specific area required for the project, and move forward with that technology comfortably.

Related: How do I migrate my skills to the cloud?

2. Customer & product perspective

When building code, it’s easy to get mired in libraries, sorting algorithms, and API minutiae. And all of that is very important. But what are you building, and why are you building it?

Understanding your customer, what they do day-to-day is not always easy. It means using the product yourself, and also talking with sales teams regularly to hear what they are hearing.

Then pouring all this into your user stories. For top engineers it will inform their decisions, and help them communicate to product & project managers about what issues their encountering. Tradeoffs about features, coding, performance and technical debt can be better evaluated with more information.

Read: Is Fred Wilson honest about transparency?

3. Dig Deeper

Does your code run slowly? Have you tried to figure out why?

Is it related to:

o latency in production that doesn’t appear our your laptop
o untuned production database queries
o untuned connection pooling
o slow API calls
o weird kubernetes or orchestration issues
o web host issue with memory shortage
o web host issue with slow unoptimized code
o issues on the client side

Top engineers have seen applications slow down or fail in a myriad of ways. This allows them to imagine how a new application might be failing, and investigate those.

Related: What mistakes did you make when starting as a consultant?

4. Great communicators

In startups, your engineers need to communicate to many folks who don’t have an engineering background. Product & UI/UX folks probably are quite technical on their own. But what about sales teams who are dealing directly with customers? Or C-suite folks who watch the business bottom lines, but may not have the same low level technical understanding?

Great communicators can find the right metaphor to explain hurdles and holdups, technical debt, or the latest performance challenges. And explaining those in terms that resonate for others is incredibly valuable to the team and business velocity.

Related: Can Mailchimp fraudulently charge your credit card?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters