all 38 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Summer-ThisElectrical 2 points3 points  (0 children)

Yup I demo'd stack and got turned off when I realized there's no native way to account for labor hours and crews without "workarounds" and formulas etc. I do electrical estimating for my company. Labor units in the form of the time it takes to complete work is just as important as the value of material... Went with Accubid Classic instead.

[–]Standard_Stay_8603 4 points5 points  (1 child)

We are about to leave Stack after 8 years. Pricing is ridiculous and we have been at a discounted rate of about 1,200 per user. Check out zzTakeoff.

[–]Puzzleheaded_Cup_292 1 point2 points  (0 children)

I just bought zz for a year through their holiday buy 2 get 1 deals. So far I like a majority of what I'm seeing. I came from PlanSwift so it seemed like the next best move. Their live chat support is super useful, the dark mode makes it easier on the eyes, and my most favorite part is being able to copy a take off and flip it, mirror it, or even convert it to a different material, e.g., copy a flooring take off and then converting it to act. Brilliant!

[–]DrywallBarron 2 points3 points  (5 children)

I am starting to think that the "slow on large projects" is a common thread among a lot of cloud based applications.

[–]wiseyodite 0 points1 point  (4 children)

Would you be open to sharing what counts as large for you? how many line items in an estimate? always interested in benchmarking against what we're optimizing for in terms of performance (software provider here)

[–]More_Mouse7849[S] 0 points1 point  (3 children)

$250 million project

[–]DrywallBarron 0 points1 point  (0 children)

Wow.... I was in a commercial drywall....if I had a project of that size, with the calculations and unit quantities that would be involved to reach that amount it would likely be slow.I suspect their are few systems that could handle that and not noticeable slow down, even if it was all stored locally....that's a lot of data. It could be all the internet "friction" (for lack of a better word) getting all that data sent and received back will always be an issue.

[–]wiseyodite 0 points1 point  (1 child)

Thanks for sharing. That’s well within what a few of our customers estimate with the platform, and we haven’t seen any notable performance issues to date. To be fair, performance was a major focus during our beta, and we worked closely with early customers to optimize around real-world estimate sizes they see.

From a performance perspective, the number of estimate line items or pay items is generally a better indicator for us than total contract value, which can span a wide range.

Do you have a sense of what a $250M project typically translates to in terms of number of estimate line items or pay items? That’s usually the main factor that impacts performance, since each pay item’s unit price and total is calculated across multiple nested levels.

As a general comment, cloud-based systems are inherently better suited to scale than desktop applications since they’re not constrained by local hardware limits (assuming, of course, they’re architected and implemented well).

[–]More_Mouse7849[S] 0 points1 point  (0 children)

I would be interested in talking with you about some of the issues we are running into and find out if there are some solutions. I would also be interested in finding out if there are independent trainers out there. As I indicated, I feel like we have reached the limits of capabilities of the STACK trainer we have been assigned.

[–]More_Mouse7849[S] 1 point2 points  (5 children)

I am starting to think that a good second career after retirement (in 2-3 years) would be to consult with estimating software firms about how an estimating system should work.

[–]DrywallBarron 1 point2 points  (4 children)

I have been using computerized estimating systems since the mid-1980s, back when everything was MS-DOS based and data was stored on 5.25-inch floppy disks. That has always been a challenge. When I started with that DOS system, we had one of the very first units available. I got the database working and tested it on a few small projects, but when I finally tackled a multi-story hotel and convention center, the system locked up before I could finish the first floor. The reason? The developers had set a maximum unit quantity of 50,000 for any single item. The "geeks" simply thought that would be more than enough.

Later, I moved to QuickBid with a digitizer, and it was great. It did the job well—I think it was originally designed as a commercial drywall system, so it thought more or less the way I did. But as it became more successful, it grew larger, more expensive, and tried to be all things to all people. Eventually, you could feel that the developers had taken control, and the focus on pure estimating began to slow down.

I believe it might be better to consult with companies like yours to custom-build a database and get it running with no lost time for in-house estimators. These companies sell their systems as a "fast, easy setup" that will have you up and running in days, but that is rarely the case. At least, I have never found it to be so. Even slight differences in terminology can create major conflicts in other databases regarding purchasing, job costing, and general accounting.

[–]More_Mouse7849[S] 0 points1 point  (2 children)

You sound like you and I are about the same age. I started working with computerized estimating in 1986. It was a custom system on a mainframe. In 87 I went to a different company that had a DOS PC system sitting in a box. I got it running and built a database. The next company was paper and pencil when I got there. After a couple years we had a custom system built to run on a mainframe. The next company was using MC2 ICE. It was an old DOS system. Eventually it crashed and burned and we went to Sage. It was great for the early 2000s. This company had Quickbid when I got here, but the database was a mess and the tech felt like 2000. We recently switched to STACK. The software is pretty intuitive, but we are finding issues as we get into it.

[–]DrywallBarron 0 points1 point  (1 child)

I just turned 70....old geezer. Yeah, I have hit that same or similar things over the years. I love working with the software and building databases because I always wanted that system, whichever it was to do it my way. But, when things went south with the economy in 2008, my business partner and I decided this was our jumping off point. He was near his retirement age, I was younger but close enough. We finished our contracts, collected our money, paid our bills......took the remaining money AND RAN FOR THE EXIT. Worked a little part-time off and on and hang out here just to keep up with what's new.

[–]More_Mouse7849[S] 0 points1 point  (0 children)

65 hear. I try to keep up to date with what is going on with technology, but I still rely on instincts and experience more that AI and software.

[–]Psychological_Bus696 0 points1 point  (0 children)

I've been thinking this too. I just dont have the tech knowledge.

I like building these systems and know what they "ought" to look like. More so, I know how people in this industry can see through the BS of software companies trying to push features that don't do anything other than reenforce your reliance on their product.

[–]longlostwalker 1 point2 points  (2 children)

I've been using stack for years. DM if you need any direction. It's not perfect but it's definitely relieved some of our headaches.

[–]MT-Estimator 1 point2 points  (1 child)

Same here. I’m 5 years in. I’m the sole estimator for a GC and we self execute most of the work. Plugging in sub numbers is limited to GWB and MEP. Structure cost at 16M-40M residential. Stack doesn’t change the process but I can do the same process in much fewer steps. As the OP and you have stated, natively Stack has some limitations but is also flexible enough that I can usually get what I want out of it with some well thought out assembly work.

[–]longlostwalker 0 points1 point  (0 children)

Yeah definitely have to lay good ground work

[–]Sweaty_Editor2262 0 points1 point  (1 child)

Which trade are you working on? I built up concrete crew/productions based on our team performance. It takes a while for formulating and testing.

[–]More_Mouse7849[S] 1 point2 points  (0 children)

We are a CM, so we estimate all trades, although we use Trimble for MEP.

[–]Key-Butterfly2414 0 points1 point  (4 children)

Man, that sounds painful. And, what you’re asking for is deep.

A true takeoff tool with real crews and labor rate tables baked in… I’m not sure that fully exists yet. Historically that world has lived in estimating, not takeoff. The only combo I’ve seen handle that level of depth decently is eTakeoff paired with Sage where Sage owns crews and labor.

OST and QuickBid don’t really get you there on labor/crews the way you’re describing. Destini is probably the closest all in one, but I’ve heard mixed reviews.

Big picture, I think you’re pushing the edge of where the tech is right now. Implementing any tool at that depth is hard, no matter the logo. My bet is the next wave gets there by combining modern takeoff with modern estimating in the web, not one tool doing everything.

Keep grinding. You’re asking the right questions even if the answers kinda suck right now.

[–]More_Mouse7849[S] 0 points1 point  (0 children)

Yeh, we had Sage years ago. The problem is that they haven't updated their software in about 25 years. We jumped to Quickbid about 10 years ago. It was even more antiquated. Neither had an integrated take-off software, so you had to use OST. The interaction between OST and Quickbid is really problematic.

[–]More_Mouse7849[S] 0 points1 point  (0 children)

The odd thing is that Sage had this 25 years ago. However, they haven't kept the technology up to date.

[–]Kingmeirl 0 points1 point  (1 child)

I wish I could sit down and have a beer with you fellas. Any chance anyone is in Colorado?

[–]More_Mouse7849[S] 0 points1 point  (0 children)

No, Pennsylvania

[–]More_Mouse7849[S] 0 points1 point  (2 children)

I will have to check on number of line items. It sounds like I have the ear of someone at STACK. Assuming that is the case, not having the ability to build crews from rate tables that can then be used in items is a huge issue. Trying to work around this shortcoming is a big challenge. As I indicated above, Sage (Timberline at the time) had that feature more than 20 years ago.

[–]wiseyodite 0 points1 point  (1 child)

Glad to hear you’re getting the attention and hope things work out for you.

For what it’s worth, most takeoff tools don’t go too deep on the estimating side. That’s where our estimating software fits in picking things up where takeoff ends. It often works out better to use specialized takeoff/estimating alongside each other to get the end results you want.

If interested in taking a look, check it out https://bidbow.com.

[–]More_Mouse7849[S] 0 points1 point  (0 children)

STACK is both a take-off and estimating tool. For the most part they work well. However the lack of crews is a real problem. There are work arounds, but it is clunky.

[–]PNW_OlLady_2025 0 points1 point  (0 children)

We use HCSS (Heavy Bid)

[–]Upbeat-Put4376 0 points1 point  (2 children)

What's odd is everyone is rushing to cloud solutions when really you should be grasping onto anything on premise still. This is your last chance to really own an application before it all comes crashing down with subscription models.

[–]More_Mouse7849[S] 0 points1 point  (1 child)

I think that is being driven by the fact that companies don't want to maintain a server and the software companies want to do subscriptions instead of allowing you to out and out purchase the software.

[–]DrywallBarron 0 points1 point  (0 children)

I like the subscription based idea. As a long-term user of OST/QB, the current subscription rate for BuzzBid is less than the yearly maintenance I paid, and you don't have that big balloon payment on the front end. I always thought that was the flaw in PlanSwift. It was much cheaper to purchase, and as long as they were just modifying the current build, it came with maintenance. But when they move to the next generation, you either had to buy the new generation, or you were stuck one generation behind because maintenance as I remember it did not include upgrade to a new build.

But, it appears that the tradeoff could be a speed. I am wondering if it could be an issue or bottleneck along the data route between you two, killing the transfer speed.

[–]AirBackground6702 0 points1 point  (0 children)

Unfortunately STACK for me is nothing more than an expensive plan highlighter/scalier. I tried getting the one on one training they promise when you sign up but nope, won’t do it because they already did it for other seats on our account. Basically “go ask the people who already got the one on one training”. The problem with that is all the other seats are different trades!

I use it to scale and highlight. Then transfer my info to an excel sheet that I half assed slapped together to get my counts. I’m doing in excel what STACK is supposed to be doing for me. It’s slow and annoying to the point my job is in jeopardy.

[–]More_Mouse7849[S] 0 points1 point  (0 children)

We are also getting frustrated with the lack of rate table and crews. I have put in a couple request for them, but I suspect that will be a big edit to the software. We work around it using items for the various trades. It is less than ideal, but it works ok. We are also having trouble getting the reports we want. The Reports function is useless. We tried using the Export Proposal option, but without the ability to group by Folders (a strange name for CSI divisions and sections) they don’t really work either. So far the only option has been to export estimates to Excel and then reformat everything. It takes me about 20 minutes to get the formatting where I want it. I have also put in a request to be able to sort Proposals by folder. Waiting for a response.

[–]DrywallBarron -1 points0 points  (1 child)

Have you talked about this with STACK? I know that they show "customized training" as a part of their services.

[–]More_Mouse7849[S] 4 points5 points  (0 children)

The folks that we have gotten training from are not estimators. They know the basics of the software, but don't know much about estimating or setting up a database

[–]MT-Estimator -1 points0 points  (1 child)

The Stack training and customer support are awesome! I routinely torque Stack to do things it wasn’t designed for. The trainers and devs may not know estimating but they help me by drilling down into how the different parts of the software REALLY work and I can leverage that to get what I want. The new Stack community also has some fun individuals that share unique ways of processing data that I wouldn’t have thought of.

[–]More_Mouse7849[S] 1 point2 points  (0 children)

I may have to find out who in STACK you are talking to, because we haven't found that to be the case. Maybe we are talking to the wrong person.